Graph-based program state notification

ABSTRACT

A method includes obtaining program state of a self-executing protocol, wherein the program state includes a set of conditional statements and a directed graph including a set of vertices and a set of directed edges, each respective vertex associated with a respective category label of a set of mutually exclusive categories. The method may include receiving an event message including a set of parameters, selecting a first subset of vertices triggered by the event message and a second subset of vertices based on the first subset of vertices. The method may include determining an aggregated parameter based on a subset of conditional statements, where each respective conditional statement is associated with a respective vertex that is associated with a first category label of the set of mutually exclusive categories. The method may include storing the aggregated parameter in persistent storage.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent claims the benefit of U.S. Provisional Patent Application62/897,240, filed 6 Sep. 2019, titled “SMART DEONTIC DATA SYSTEMS.” Thispatent also claims the benefit of U.S. Provisional Patent Application62/959,418, filed 10 Jan. 2020, titled “GRAPH-MANIPULATION BASEDDOMAIN-SPECIFIC ENVIRONMENT.” This patent also claims the benefit ofU.S. Provisional Patent Application 62/959,481, filed 10 Jan. 2020,titled “GRAPH OUTCOME DETERMINATION IN DOMAIN-SPECIFIC EXECUTIONENVIRONMENT.” This patent also claims the benefit of U.S. ProvisionalPatent Application 62/959,377, filed 10 Jan. 2020, titled “SMART DEONTICMODEL AND SYSTEMS.” This patent also claims the benefit of U.S.Provisional Patent Application 63/020,808, filed 6 May 2020, titled“GRAPH EXPANSION AND OUTCOME DETERMINATION FOR GRAPH-DEFINED PROGRAMSTATES.” This patent also claims the benefit of U.S. Provisional PatentApplication 63/033,063, filed 1 Jun. 2020, titled “MODIFICATION OFIN-EXECUTION SMART CONTRACT PROGRAMS.” This patent also claims thebenefit of U.S. Provisional Patent Application 63/034,255, filed 3 Jun.2020, titled “SEMANTIC CONTRACT MAPS.” This patent also claims thebenefit of U.S. patent application Ser. No. 16/893,290, filed 4 Jun.2020, titled “GRAPH-MANIPULATION BASED DOMAIN-SPECIFIC EXECUTIONENVIRONMENT.” This patent also claims the benefit of U.S. patentapplication Ser. No. 16/893,318, filed 4 Jun. 2020, titled “GRAPHOUTCOME DETERMINATION IN DOMAIN-SPECIFIC EXECUTION ENVIRONMENT.” Thispatent also claims the benefit of U.S. patent application Ser. No.16/893,295, filed 4 Jun. 2020, titled “MODIFICATION OF IN-EXECUTIONSMART CONTRACT PROGRAMS.” This patent also claims the benefit of U.S.patent application Ser. No. 16/893,299, filed 4 Jun. 2020, titled “GRAPHEXPANSION AND OUTCOME DETERMINATION FOR GRAPH-DEFINED PROGRAM STATES.”This patent also claims the benefit of U.S. Provisional PatentApplication 63/052,329, filed 15 Jul. 2020, titled “EVENT-BASED ENTITYSCORING IN DISTRIBUTED SYSTEMS.” This patent also claims the benefit ofU.S. Provisional Patent Application 63/053,217, filed 17 Jul. 2020,titled “CONFIDENTIAL GOVERNANCE VERIFICATION FOR GRAPH-BASED SYSTEM.”This patent also claims the benefit of U.S. Provisional PatentApplication 63/055,783, filed 23 Jul. 2020, titled “HYBRID DECENTRALIZEDCOMPUTING ENVIRONMENT FOR GRAPH-BASED EXECUTION ENVIRONMENT.” Thispatent also claims the benefit of U.S.

Provisional Patent Application 63/056,984, filed 27 Jul. 2020, titled“MULTIGRAPH VERIFICATION.” The entire content of each aforementionedpatent filing is hereby incorporated by reference.

BACKGROUND 1. Field

This disclosure relates generally to computer systems and, moreparticularly, to graph-manipulation based domain-specific executionenvironments.

2. Background

Distributed applications operating on a distributed computing platformmay be useful in a variety of contexts. Such applications can storeprogram state data on a tamper-evident ledger operating on thedistributed computing platform. The use of a tamper-evident ledger orsome other data systems distributed over multiple computing devices mayincrease the security and reliability of distributed applications.

SUMMARY

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

Some aspects include a process that includes obtaining program state ofa self-executing protocol and a set of entities, where the set ofentities includes a first entity, where the program state includes a setof conditional statements and a directed graph. The directed graphincludes a set of vertices and a set of directed edges connectingrespective pairs of vertices among the set of vertices, where eachrespective vertex of the set of vertices is associated with a respectivecategory label of a set of mutually exclusive categories. The processmay include receiving, at an application program interface, an eventmessage including a set of parameters and selecting a first subset ofvertices triggered by the event message based on the set of parameters.The process may include selecting a second subset of vertices based onthe first subset of vertices, where the second subset of vertices isassociated with the first subset of entities via the set of directededges. The process may include determining an aggregated parameter basedon a subset of conditional statements, where each respective conditionalstatement of the subset of conditional statements is associated with arespective vertex of the second subset of vertices, and where therespective vertex is associated with a first category label of the setof mutually exclusive categories that is shared by each of the otherrespective vertices associated with the subset of conditionalstatements. The process may include storing the aggregated parameter inpersistent storage.

Some aspects include a tangible, non-transitory, machine-readable mediumstoring instructions that when executed by a data processing apparatuscause the data processing apparatus to perform operations including theabove-mentioned process.

Some aspects include a system, including: one or more processors; andmemory storing instructions that when executed by the processors causethe processors to effectuate operations of the above-mentioned process.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following figures in which like numbers indicate similar oridentical elements:

FIG. 1 is a flowchart of an example of a process by which program statedata of a program may be deserialized into a directed graph, updatedbased on an event, and re-serialized, in accordance with someembodiments of the present techniques.

FIG. 2 depicts a data model of program state data, in accordance withsome embodiments of the present techniques.

FIG. 3 is flowchart of an example of a process by which a program maysimulate outcomes or outcome scores of symbolic AI models, in accordancewith some embodiments of the present techniques.

FIG. 4 show a computer system for operating one or more symbolic AImodels, in accordance with some embodiments of the present techniques.

FIG. 5 includes a set of directed graphs representing triggered normsand their consequent norms, in accordance with some embodiments of thepresent techniques.

FIG. 6 includes a set of directed graphs representing possiblecancelling relationships and possible permissive relationships betweennorms, in accordance with some embodiments of the present techniques.

FIG. 7 includes a set of directed graphs representing a set of possibleoutcome states based on events corresponding to the satisfaction orfailure of a set of obligations norms, in accordance with someembodiments of the present techniques.

FIG. 8 includes a set of directed graphs representing a set of possibleoutcome states after a condition of a second obligations norm of a setof obligations norms is not satisfied, in accordance with someembodiments of the present techniques.

FIG. 9 includes a set of directed graphs representing a set of possibleoutcome states after a condition of a third obligations norm of a set ofobligations norms is not satisfied, in accordance with some embodimentsof the present techniques.

FIG. 10 includes a set of directed graphs representing a pair ofpossible outcome states after a condition of a fourth obligations normof a set of obligations norms is not satisfied, in accordance with someembodiments of the present techniques.

FIG. 11 is a block diagram illustrating an example of a tamper-evidentdata store that may be used to render program state tamper-evident andperform the operations in this disclosure, in accordance with someembodiments of the present techniques.

FIG. 12 depicts an example logical and physical architecture of anexample of a decentralized computing platform in which a data store ofor process of this disclosure may be implemented, in accordance withsome embodiments of the present techniques.

FIG. 13 shows an example of a computer system by which the presenttechniques may be implemented in accordance with some embodiments.

FIG. 14 depicts a diagram of an entity graph, in accordance with someembodiments of the present techniques.

FIG. 15 is a flowchart of a process to assign an outcome score based ona graph portion, in accordance with some embodiments of the presenttechniques.

FIG. 16 is a flowchart of a process to send a message indicating that anentity score has been updated based on an entity graph, in accordancewith some embodiments of the present techniques.

FIG. 17 shows an example of a computer system usable to determine a setof governing conditions, in accordance with some embodiments.

FIG. 18 shows a flowchart of operations to update an entity profilebased on whether a set of governing conditions are satisfied, inaccordance with one or more embodiments.

FIG. 19 shows a flowchart of operations to determine a set of governingconditions based on obtained documents, in accordance with one or moreembodiments.

FIG. 20 depicts a logical and physical architecture diagram usable fordetermining aggregate parameters, in accordance with some embodiments ofthe present techniques.

FIG. 21 is a flowchart of a process to determine aggregated parameters,in accordance with some embodiments of the present techniques.

FIG. 22 depicts a user interface that displays aggregated parameters, inaccordance with some embodiments of the present techniques.

While the present techniques are susceptible to various modificationsand alternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit thepresent techniques to the particular form disclosed, but to thecontrary, the intention is to cover all modifications, equivalents, andalternatives falling within the spirit and scope of the presenttechniques as defined by the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

To mitigate the problems described herein, the inventors had to bothinvent solutions and, in some cases just as importantly, recognizeproblems overlooked (or not yet foreseen) by others in the field ofprogram testing. Indeed, the inventors wish to emphasize the difficultyof recognizing those problems that are nascent and will become much moreapparent in the future should trends in industry continue as theinventors expect. Further, because multiple problems are addressed, itshould be understood that some embodiments are problem-specific, and notall embodiments address every problem with traditional systems describedherein or provide every benefit described herein. That said,improvements that solve various permutations of these problems aredescribed below.

Technology-based self-executing protocols, such as smart contracts andother programs, allow devices, sensors, and program code have seenincreased use in recent years. However, some smart contracts andcontract information models often rely on program instructions orindustry-specific data structures, which may be difficult to generalize,use for comparison analysis, or reuse in similar contexts due to minordifferences in contract details. As a result, uses of smart contractshas not extended into areas that are often the domain of naturallanguage documents. Described herein is a process and related system toconstruct, interpret, enforce, analyze, and reuse terms for a smartcontract in a systematic and unambiguous way across a broad range ofapplicable fields. In contrast, contracts encoded in natural languagetext often rely on social, financial, and judicial systems to providethe resources and mechanisms to construct, interpret, and enforce termsin the contracts. As contract terms increase in number or a situationwithin which the contract was formed evolves, such a reliance may leadto a lack of enforcement, ambiguity, and wasted resources spent on there-interpretation or enforcement of contract terms.

Some embodiments may include smart contracts (or other programs) thatinclude or are otherwise associated with a directed graph representing astate of the smart contract. In some embodiments, vertices of the graphmay be associated with (e.g., encode, or otherwise represent) norms(e.g., as norm objects described below) of the smart contract, likeformal language statements with a truth condition paired with aconditional statement (sometimes known as a “conditional”) that branchesprogram flow (and changes norm state) responsive to the whether thetruth condition is satisfied, for instance, “return a null response ifand only if an API request includes a reserved character in a datafield.” In some embodiments, norms of a smart contract may representterms of a contract being represented by the smart contract, legalconditions of the contract, or other verifiable statements. As usedherein, a smart contract may be a self-executing protocol executable asa script, an application, or portion of an application on a distributedcomputing platform, centralized computing system, or single computingdevice. Furthermore, as used herein, a graph may be referred to as asame graph after the graph is manipulated. For example, if a graph beingreferred to as a “first graph” is represented by the serialized array[[1,2], [2,3], [3,4]] is modified to include the extra vertex and graphedge “[1,5]” and become the modified graph represented by the serializedarray “[[1,2], [2,3], [3,4], [1,5]],” the term “first graph” may be usedto refer to the modified graph. Additionally, it should be understoodthat a data structure need not be labeled in program code as a graph toconstitute a graph for the present purposes, as long as that datastructure encodes the relationships between values described herein. Forexample, a graph may be encoded in a key-value store even if source codedoes not label the key-value store as a graph.

A self-executing protocol may be a program, like a smart contract.Self-executing protocols may execute responsive to external events,which may include outputs of third-party programs, and human input via auser interface. A self-executing protocol may execute on a computingsubstrate that involves human intervention to operate, like turning on acomputer and launching an event listener.

A norm of a smart contract may be encoded in various formal languages(like programming languages, such as data structures encoding statementsin a domain-specific programming language) and may include or otherwisebe associated with one or more conditional statements, a set of normconditions of the one or more conditional statements, a set of outcomesubroutines of the one or more conditional statements, a norm status,and a set of consequent norms. In some embodiments, satisfying a normcondition may change a norm status and lead to the creation oractivation of the consequent norms based on the actions performed by thesystem when executing the outcome subroutines corresponding to thesatisfied norm condition. In some embodiments, a norm may be triggered(i.e. “activated”) when an associated norm condition is satisfied by anevent, as further described below. Alternatively, some types of normsmay be triggered when a norm condition is not satisfied before acondition expiration threshold is satisfied. As used herein, atriggerable norm (i.e. “active norm”) is a norm having associated normconditions may be satisfied by an event. In contrast, a norm that is setas not triggerable (i.e. “inactive”) is a norm is not updated even ifits corresponding norm conditions are satisfied. As used herein,deactivating a norm may include setting the norm to not be triggerable.

A smart contract and its norms may incorporate elements of a deonticlogic model. A deontic logic model may include a categorization of eachof the norms into one of a set of deontic primitive logical categories.A deontic primitive logical category (“logical category”) may include alabel such as “right,” “obligation,” or “prohibition.” The logicalcategory may indicate a behavior of the norm when the norm is triggered.In addition, a norm of the smart contract may have an associated normstatus such as “true,” “false,” or “unrealized,” where an event maytrigger a triggerable norm by satisfying a norm condition (and thus“realizing” the norm). These events may be collected into a knowledgelist. The knowledge list may include an associative array of norms,their associated states, an initial norm status during the initialinstantiation of the associated smart contract, their norm observationtimes (e.g., when a norm status was changed, when an event message wasreceived, or the like), or other information associated with the norms.The smart contract may also include a set of consequent actions, where aconsequent action may include an association between a triggered normand any respective consequent norms of the smart contract. As furtherdiscussed below, the set of consequent actions may be updated as eventsoccur and the smart contract state is updated, which may result in theformation of a history of previous consequent actions. It should beunderstood that the term “norm” is used for illustrative purposes andthat this term may have different names in other references andcontexts. The labeling of norms may also be used for symbolic artificialintelligence (AI) systems. As described further below, the use of thesesymbolic AI systems in the context of a smart contract may allow forsophisticated verification and predictive techniques that may beimpractical for pure neural network systems which do not use symbolic AIsystems. It should be understood that, while the term “logical category”is used in some embodiments, other the terms may be used for categoriesor types of categories without loss of generality. For example, someembodiments may refer to the use of a “category label” instead of alogical category.

Some embodiments may store a portion of the smart contract state in adata serialization format (“serialized smart contract state data”). Forexample, as further described below, some embodiments may store avertices of a directed graph (or both vertices and edges) in a dataserialization format. In response to determining that an event hasoccurred, some embodiments may deserialize the serialized smart contractstate data into a deserialized directed graph. In some embodiments, avertex (a term used interchangeably with the term node) of the directedgraph may be associated with a norm from a set of norms of the smartcontract and is described herein as a “norm vertex,” among other terms,where a norm vertex may be connected one or more other norm vertices viagraph edges of the directed graph. Some embodiments may then update thedirected graph based on a set of consequent norms and their associatedconsequent norm vertices, where each of the consequent norms aredetermined based on which norms were triggered by the event and whatnorm conditions are associated with those active norms. The updateddirected graph may then be reserialized to update the smart contract. Insome embodiments, a norm vertex may not have any associated conditions.In some embodiments, the amount of memory used to store the serializedsmart contract state data may be significantly less than the memory usedby deserialized smart contract state data. During or after the operationto update the smart contract, some embodiments may send a message toentities listed in a list of entities (such as an associative array ofentities) to inform the entities that the smart contract has beenupdated, where the smart contract includes or is otherwise associatedwith the list of entities. Furthermore, it should be understood in thisdisclosure that a vertex may include (or comprise) a condition by beingassociated with the condition. For example, a norm vertex may include afirst norm condition by including a reference pointer to the first normcondition.

In some embodiments, generating the smart contract may include using anintegrated development environment (IDE) and may include importinglibraries of provisions re-used across agreements. Furthermore, someembodiments may generate a smart contract based on the use of naturallanguage processing (NLP), as further described below. For example, someembodiments may apply NLP operations to convert an existing prosedocument into a smart contract using operations similar to thosedescribed for patent application 63/034,255, titled “Semantic ContractMaps,” which is herein incorporated by reference. For example, someembodiments may apply a set of linear combinations of featureobservations and cross observations across first order and second ordersin feature space to determine a smart contract program or other symbolicAI program. Alternatively, or in addition, some embodiments may includeconstructing a smart contract from a user interface or text editorwithout using an existing prose document. In some embodiments, the smartcontract may be encoded in various forms, such as source code, bytecode,or machine code encodings. In some embodiments, a smart code may begenerated or modified in one type of encoding and be converted toanother type of encoding before the smart code is used. For example, asmart contract may be edited in a source code encoding, and the smartcontract may be executed by converting the smart contract into abytecode encoding executing on a distributed computing platform. As usedherein, a smart contract may be referred to as a same smart contractbetween different encodings of the smart contract. For example, a smartcontract may be written in source code and then converted to a machinecode encoding, may be referred to as a same smart contract.

Furthermore, as used herein, the sets of items of a smart contract datamodel may be encoded in various formats. A set of items be encoded in anassociative array, a b-tree, a R-tree, a stack, or various other typesof data structures. As used herein, the sets of items in the data modelmay be determined based on their relationships with each other. Forexample, a set of entities may be encoded as an associative array ofentities or may be encoded as an entities b-tree, and elements of aknowledge list may include references to an entity in the set ofentities for either type of encoding. In some embodiments, sets of itemsin their respective data models may be based on the underlyingrelationships and references between the items in the sets of items, andembodiments should not be construed as limited to specific encodingformats. For example, while some embodiments may refer to an associativearray of norms, it should be understood that other embodiments may use ab-tree to represent some or all of the set of norms.

A smart contract may be stored on different levels of a memoryhierarchy. A memory hierarchy of may include (in order of fastest toslowest with respect to memory access speed) processor registers, Level0 micro operations cache, Level 1 instructions cache, Level 2 sharedcache, Level 3 shared cache, Level 4 shared cache, random access memory(RAM), a persistent flash memory, hard drives, and magnetic tapes. Forexample, a Level 1 cache of a computing device may be faster than a RAMof the computing device, which in turn may be faster than a persistentflash memory of the computing device. In some embodiments, the memory ofa computing device at a first layer of the memory hierarchy may have alower memory capacity than a memory of the computing device at a slowerlayer of the memory hierarchy. For example, a Level 0 cache may memorycapacity of 6 kibibytes (KiB), whereas a Level 4 cache may have a memorycapacity of 128 mebibytes (MiB). In some embodiments, memory may befurther distinguished between persistent storage and non-persistentstorage (i.e. “non-persistent memory”), where persistent storage iscomputer memory that may retain the values stored in it without anactive power source. For example, persistent storage may includepersistent flash memory, hard drives, or magnetic tape, andnon-persistent memory may include processor registers, cache memory, ordynamic RAM. In some embodiments, a smart contract may be stored onmemory at different levels of the memory hierarchy to increase storageefficiency of the smart contract. For example, serialized smart contractstate data of the smart contract may be stored on RAM of a computingdevice while the deserialized smart contract state data may be stored ona cache of the computing device.

In some embodiments, the smart contract may update infrequently, such asless than once per hour, less than once day, less than once per month,or the like. The relative infrequency of the updates can mean that therelative computing resources required to deserialize and reserializedata be significantly less than the computing resources required tomaintain deserialized data in higher-speed memory. In some embodiments,the dynamic program state By serializing a portion of the smart contractdata and persisting the serialized data instead of the correspondingdeserialized data to a persistent storage, a computing system may usereduce the memory requirements of storing and executing the smartcontract. In addition, the computing system may also increase the numberof smart contracts being executed concurrently by a distributedcomputing platform or single computing device. Furthermore, as usedherein, updating a value may include changing the value or generatingthe value.

As described herein, some embodiments may store smart contract data inother forms. For example, while some embodiments may temporarily store adirected graph in non-persistent storage, some embodiments may store thedirected graph on a persistent storage. In some embodiments, variousother types of information such as norm statuses (e.g. “triggered,”“failed,” “satisfied,” etc.) or logical categories (e.g. “rights,”“obligation,” “prohibition,” etc.) may be included in or otherwiseassociated with some or all of the vertices of the directed graph.Furthermore, some embodiments may generate visual display representingof the program state data to show the directed graph and its associatedstatuses, categories, or other information. For example, as furtherdescribed below, some embodiments may display the directed graph as ahierarchical visual element such as a hierarchy tree in a webapplication.

A smart contract may be implemented in various ways. For example, someembodiments may construct, enforce, or terminate the smart contractusing a distributed ledger or distributed computing system.Alternatively, some embodiments may implement the smart contract using arequest-response system over a public or private internet protocol (IP)network. Use of the methods described herein may increase the efficiencyof smart contract enforcement by advancing the state of complexmulti-entity agreements in a fast and unambiguous way. Furthermore,implementing and using smart contracts with the embodiments describedherein may allow for the comparison, quantification, and reuse of smartcontracts in a way that would be inapplicable to custom-coded smartcontracts.

In some embodiments, the smart contract may be stored in atamper-evident data-store. As discussed below, tamper-evident datastores (e.g., repositories rendering data tamper-evident with one ormore tamper-evident data structures) afford desirable properties,including making it relatively easy to detect tampering with entries inthe data store and making it relatively difficult or impossible totailor entries to avoid such detection. Furthermore, various smartcontracts may be operating across one or more nodes of thetamper-evident data store, reducing the susceptibility of the smartcontract to regional disturbances.

None of the preceding should be taken to suggest that any technique isdisclaimed or that the approaches described herein may not be used inconjunction with other approaches having these or other describeddisadvantages, for instance, some embodiments may use a custom-writtensmart-contract that includes one or more of the norms, data structures,or graphs described herein. Or some embodiments may store a directedgraph without serialization or deserialization operations. Or someembodiments may be implemented on a centralized server without storingsmart contract state data on a distributed computing system such as adecentralized computing system. Further, it should be emphasized thatthe data structures, concepts, and instructions described herein maybear labels different from those applied here in program code, e.g., adata structure need not be labeled as a “node” or a “graph” in programcode to qualify as such, provided that the essential characteristics ofsuch items are embodied.

In some embodiments, the processes and functionality described hereinmay be implemented as computer code stored on a tangible,non-transitory, machine-readable medium, such that when instructions ofthe code are executed by one or more processors, the describedfunctionality may be effectuated. For example, the processes 100 of FIG.1 (or any of the other processes described in this disclosure) may beimplemented as computer code stored on a non-transitory machine-readablemedium. like Instructions may be distributed on multiple physicalinstances of memory, e.g., in different computing devices, or in asingle device or a single physical instance of memory (e.g.,non-persistent memory or persistent storage), all consistent with use ofthe singular term “medium.” In some embodiments, the operations may beexecuted in a different order from that described, some operations maybe executed multiple times per instance of the process's execution, someoperations may be omitted, additional operations may be added, someoperations may be executed concurrently and other operations may beexecuted serially, none of which is to suggest that any other featuredescribed herein is not also amenable to variation.

FIG. 1 is a flowchart of an example of a process by which program statedata of a program may be deserialized into a directed graph, updatedbased on an event, and re-serialized, in accordance with someembodiments of the present techniques. In some embodiments, the process100, like the other processes and functionality described herein, may beimplemented by a system that includes computer code stored on atangible, non-transitory, machine-readable medium, such that wheninstructions of the code are executed by one or more processors, thedescribed functionality may be effectuated. Instructions may bedistributed on multiple physical instances of memory, e.g., in differentcomputing devices, or in a single device or a single physical instanceof memory, all consistent with use of the singular term “medium.” Insome embodiments, the operations may be executed in a different orderfrom that described. For example, while the process 100 may be describedas performing the operations of block 112 before block 124, theoperations of block 124 may be performed before the operations of block112. As another example, while the process 3600 may be described asperforming operations of block 3602 before performing operations ofblock 3604, the operations of block 3604 may be performed before theoperations of block 3602. Some operations may be executed multiple timesper instance of the process's execution, some operations may be omitted,additional operations may be added, some operations may be executedconcurrently and other operations may be executed serially, none ofwhich is to suggest that any other feature described herein is not alsoamenable to variation.

In some embodiments, the process 100 includes determining that an eventhas occurred based on an event message, a calculation, or a conditionexpiration threshold, as indicated by block 104. In some embodiments,the system may determine that an event has occurred after receiving anevent message at an API of the system indicating that the event hasoccurred. As used herein, an event message may be transmitted across ormore packets over a wired or wireless connection, where a system maycontinuously, periodically, or be activated to listen for an eventmessage. In some embodiments, as described further below, an eventmessage may be transmitted over a public or private IP network.Alternatively, or in addition, the event message may be transmitted viathe channels of a distributed computing system. For example, the eventmessage may be transmitted from a first node of a distributed computingsystem (e.g., a blockchain platform) to a second node of the distributedcomputing system, where the first node and second node may be atdifferent geographic locations (e.g., different nodes executing ondifferent computing devices) or share a same geographic location (e.g.,different nodes executing on a same computing device). Furthermore, anevent message may be sent by a first smart contract executing on a firstcomputing distributed platform to a second smart contract executing on asame or different distributed computing platform. In some embodiments,determining than event has occurred does not require verification thatthe event has occurred. For example, in some embodiments, receiving anevent message indicating an event has occurred may be sufficient for thesystem to determine that the event occurred. Furthermore, in someembodiments, a norm vertex may be triggered based on an event satisfyinga subset of its associated norm conditions. Alternatively, a norm vertexmay be triggered only after an event satisfies all of its associatednorm conditions.

In some embodiments, the event may include satisfying a conditionexpiration threshold associated with a triggerable norm vertex (herein“triggerable vertex”) without satisfying a norm condition associatedwith the triggerable vertex, where a norm condition may be various typesof conditions implemented in a computer-readable form to return a value(e.g., “True,” “False,” set of multiple binary values, or the like). Forexample, a norm condition may include an “if” statement to test whethera payload containing a set of values was delivered to an API of thesystem by a specific date, where a condition expiration threshold isassociated with the norm condition. After the specific date is reached,the system may determine that the condition expiration threshold issatisfied and determine whether the associated norm condition issatisfied. In response to a determination that the norm condition is notsatisfied, the system may determine that an event has occurred, wherethe event indicates that a condition expiration threshold associatedwith a triggered norm vertex (herein “triggered vertex”) is satisfiedand that an associated norm condition of the triggered vertex is notsatisfied. As further stated below, such an event may trigger theassociated norm vertex and result in the activation of a set of norms,where the activation of the set of norms may be represented by thegeneration or association of an adjacent vertex to the triggered vertex,where the adjacent vertex may be updated to be triggerable. As used inthis disclosure, it should be understood that satisfying the conditionexpiration threshold of a triggerable vertex does satisfy a conditionassociated with the triggerable vertex.

In some embodiments, the event message may include a publisheridentifier to characterize a publisher of the event message. As usedherein, a publisher may be an entity and may include various sources ofan event message. For example, a publisher may include a publisher in apublisher-subscriber messaging model or a sender of a response orrequest in a response-request messaging model. In some embodiments, thepublisher identifier may be an entity identifier that is a specific nameunique to a source of the event message. For example, a publisheridentified by the publisher identifier “BLMBRG” may be transmitted inthe event message, where “BLMBRG” is unique to a single publisher.Alternatively, or in addition, a publisher identifier may include or beotherwise associated with an identifier corresponding to an entity typethat may be assigned to one or more sources of event messages. Forexample, the publisher identifier may include or otherwise be associatedwith an entity type such as “TRUSTED-VENDOR,” “ADMIN”, or the like.

After receiving a publisher identifier, the system may determine whetherthe publisher identifier is associated with one of a set of authorizedpublishers with respect to the event indicated by the event message. Insome embodiments, the system may refer to a set of authorized publisherscorresponding to the event indicated by the event message. For example,the event message may indicate that an event associated with the eventmessage “PAY DELIVERED” has occurred. In in response, the system maydetermine that the event satisfies an condition threshold, wheresatisfying the condition threshold may include a determination that theevent satisfies one or more norm conditions in an associative array ofconditions and that the associated publisher is authorized to deliverthe message. The associative array of conditions may include a list ofnorm conditions that, if satisfied, may result in triggering at leastone triggerable vertex of the smart contract. For example, the systemmay determine that the event “PAY DELIVERED” is a direct match with thenorm condition “if(PAY DELIVERED)” of the associative array ofconditions. In some embodiments, the system may then refer to the set ofauthorized publishers associated with the event “PAY DELIVERED.” Thesystem may then determine whether the publisher identifier is in the setof authorized publishers or otherwise associated with the set ofauthorized publishers, such as by having an entity type representing theset of authorized publishers. In some embodiments, if the systemdetermines that the event message is not authorized, the event messagemay be rejected as not authorized.

In some embodiments, the operation to authorize the event may include aoperations represented by Statement 1 or Statement 2 below, where “prop”may be a string value including an event and “pub” may be a string valuerepresenting a publisher identifier or entity type. In some embodiments,Statement 1 below may represent an authorization operation that includesthe arrival of an event E[pub] from publisher pub. The system may thencompare the publisher “P[E[pub]]” of the event “E[pub]” with each of aset of authorized publishers “D[E[prop]][pub]”, where each of the set ofauthorized publishers is authorized to publish the event “E[prop]”. Insome embodiments, the set of entities may include or otherwise beassociated with the set of authorized publishers. Statement 2 mayrepresent the situation which a plurality of entities may publish avalid event and the systems authorizes a message based on the entitytype “P[E[pub]][role]” being in the set of authorized publishers“D[E[prop]][pub],” where the set of authorized publishers“D[E[prop]][pub]” may include authorized publisher type:

D[E[prop]][pub]==P[E[pub]]  (1)

D[E[prop]][pub]==P[E[pub]][role]  (2)

In some embodiments, the set of authorized publishers may include a setof publisher identifiers, and the publisher identifier may in the set ofpublisher identifiers. For example, if the publisher identifier is“BLMBRG” and the set of authorized publishers include “BLMBRG,” thesystem may determine that an event message including the publisheridentifier “BLMBRG” is authorized. Alternatively, or in addition, theset of authorized publishers may include one or more authorized entitytypes and a respective publisher may be an authorized publisher if therespective publisher identifier is associated with the authorized entitytype. For example, if the publisher identifier is “BLMBRG,” and if theset of authorized publishers include the entity type “AUTH_PROVIDERS,”and if “BLMBRG” is associated with “AUTH_PROVIDERS” via an associativearray, then the system may determine that the publisher identifier isassociated with the set of authorized publishers. In response, thesystem may determine that the event message including the publisheridentifier “BLMBRG” is authorized. In some embodiments, the system maydetermine that one or more events indicated by the event message hasoccurred only after determining that the event message is authorized.

In some embodiments, the event message may include a signature valueusable by the system to compute a cryptographic hash value. Furthermore,some event messages may include the event payload with the signaturevalue (e.g., via string concatenation) to compute the cryptographic hashvalue. The system may use various cryptographic hashing algorithms suchas SHA-2, Bcrypt, Scrypt, or the like may be used to generate acryptographic hash value. In some embodiments, the system may usesalting operations or peppering operations to increase protection forpublisher information. In some embodiments, the system may retrieve acryptographic certificate based on a publisher identifier as describedabove and authenticate the event message after determining that on thecryptographic hash value satisfies one or more criteria based on thecryptographic certificate. A cryptographic certificate may include acryptographic public key used to compare with the cryptographic hashvalue, as further discussed below. In addition, the cryptographiccertificate may also include one or more second cryptographic valuesindicating a certificate issuer, certificate authority private key,other certificate metadata, or the like.

In some embodiments, a smart contract may include or be associated witha plurality of cryptographic certificates. The system may determine ofwhich cryptographic certificate to use may be based on a map of entitiesof the smart contract. In some embodiments, the operation toauthenticate the event may include a statement represented by Statement3 below, where “v” may represent a signature verification algorithm,E[sig] may represent a signature value of an event object “E,”“P[E[pub]]” may represent a data structure that includes the entity thathad published the event E, and P[E[pub]][cert] may represent acryptographic certificate value such as cryptographic public key:

v(E[sig],P[E[pub]][cert])==True  (3)

Various signature verification algorithms may be used to authenticate anevent message based on a signature value of the event message. Forexample, the system may determine that the cryptographic hash value isequal to the cryptographic certificate, and, in response, authenticatethe event message. In some embodiments, the system may determine thatone or more events indicated by the event message has occurred onlyafter authenticating the event message.

In some embodiments, the system may determine that an event has occurredbased on a determination that a condition expiration threshold has beenreached. One or more norms represented by norm vertices in the smartcontract may include a condition expiration threshold such as anobligation that must be fulfilled by a first date or a right thatexpires after a second date. For example, a smart contract instanceexecuting on the system may include a set of condition expirationthresholds, where the set of condition expiration thresholds may includespecific dates, specific datetimes, durations from a starting point,other measurements of time, other measurements of time intervals, or thelike. The system may check the set of condition expiration thresholds todetermine if any of the condition expiration thresholds have beensatisfied.

An event message may be transmitted under one of various types ofmessaging architecture. In some embodiments, the architecture may bebased on a representational state transfer (REST) system, where theevent message may be a request or response. For example, a system mayreceive a request that includes the event message, where the requestincludes a method identifier indicating that the event message is storedin the request. As an example, the system may receive a request thatincludes a “POST” method indicator, which indicates that data is in therequest message. In addition, the request my include a host identifier,where the host identifier indicates a host of the smart contract beingexecuted by the system. For example, the host identifier may indicate aspecific computing device, a web address, an IP address, a virtualserver executing on a distribute computing platform, a specific node ofa decentralized computing system, or the like.

In some embodiments, the architecture may be based on apublisher-subscriber architecture such as the architecture of theadvanced message queuing protocol (AMQP), where the event message may bea either a publisher message or subscriber message. For example, usingthe AMQP, a client publisher application may send an event message overa TCP layer to an AMQP server. The event message may include a routingkey, and the AMQP server may act as a protocol broker that distributesthe event message to the system based on the routing key after storingthe event message in a queue. In some embodiments, the system may be asubscriber to the client publisher application that sent the eventmessage.

In some embodiments, the process 100 includes determining which smartcontracts of a set of active smart contracts that will change statebased on the event, as indicated by block 108. As discussed above, insome embodiments, the system may determine that the event satisfies oneor more norm conditions, and, in response, determine that the instanceof the smart contract will change state. For example, as furtherdiscussed below, the system may determine that the event indicated“PAYLOAD 0105 PROVIDED” satisfies the norm condition represented by thecondition “IF DELI VERED(PAYLOAD),” In response, the system maydetermine that the smart contract will change state. Alternatively, orin addition, as discussed above, the system may determine that the eventdoes not satisfy one or more norm conditions but does satisfy acondition expiration threshold. In response, the system may determinethat the instance of the smart contract will change state based on theevent not satisfying one or more norm conditions while having satisfiedthe condition expiration threshold. Furthermore, while this disclosuremay recite the specific use of a smart contract program in certainsections, some embodiments may use, modify, or generate other symbolicAI programs in place of a smart contract, where symbolic AI programs arefurther discussed below.

In some embodiments, the system may include or otherwise have access toa plurality of smart contracts or smart contract instances. The systemmay perform a lookup operation to select which of the smart contracts toaccess in response to determining that an event has occurred. In someoperations, the smart contract may compare an event to the associativearray of conditions corresponding to each of a set of smart contracts toselect of the set of smart contracts should be updated and filter outsmart contracts that would not change state based on the event. Thesystem may then update each of the smart contract instances associatedwith a changed norm status, as discussed further below. Furthermore, thesystem may then update the respective associative array of conditionscorresponding to the set of smart contracts. In some embodiments, anassociative array of conditions may include only a subset of normconditions associated with a smart contract, where each the subset ofnorm conditions is associated with a triggerable vertex of the smartcontract. In some embodiments, the system may first deduplicate the normconditions before performing a lookup operation to increase performanceefficiency. For example, after determining that an event has occurred,some embodiments may search through a deduplicated array of normconditions. For each norm condition that the event would trigger, thesystem may then update the one or more smart contracts associated withthe norm condition in the deduplicated array of norm conditions. Byselecting smart contracts from a plurality of smart contracts based onan array of norm conditions instead of applying the event to the normconditions associated with the norm vertices of each of the set of smartcontracts, the system may reduce computations required to update a setof smart contracts.

The smart contract or associated smart contract state data may be storedon various types of computing systems. In some embodiments, the smartcontract state data may be stored in a centralized computing system andthe associated smart contract may be executed by the centralizedcomputing system. Alternatively, or in addition, the smart contract orassociated smart contract state data may be stored on a distributedcomputing system (like a decentralized computing system) and theassociated smart contract may be executed using a decentralizedapplication. Fore example, the smart contract may be stored on andexecuted by a Turing-complete decentralized computing system operatingon a set of peer nodes, as further described below.

In some embodiments, the smart contract data may include or be otherwiseassociated with a set of entities, such as a set of entities encoded asan associative array of entities. The associative array of entities thatmay include one or more entities that may interact with or view at leasta portion of the data associated with the smart contract. In someembodiments, the associative array of entities may include a firstassociative array, where keys of the first associative array mayindicate specific smart contract entities (e.g. data observers,publishers, or the like), and where each of the keys may correspond witha submap containing entity data such as a full legal name, a legalidentifier such as a ISIN/CUSIP and an entity type of the entity such as“LENDER,” “BORROWER”, “AGENT,” “REGULATOR,” or the like. In someembodiments, one or more entities of the associative array of entitiesmay include or be associated with a cryptographic certificate such as acryptographic public key. As described above, the cryptographiccertificate may be used to authenticate an event message or othermessage. By including authorization or authentication operations, thesystem may reduce the risk that an unauthorized publisher sends an eventmessage or that the event message from a publisher is tampered withoutthe system determining that tampering had occurred. In addition,authorization or authentication operations increase the non-repudiationof event messages, reducing the risk that a publisher may later disclaimresponsibility for transmitting an event message.

In some embodiments, the smart contract may also include or otherwise beassociated a set of conditions, such as a set of conditions encoded asan associative array of conditions. In some embodiments, the associativearray of conditions may include a set of norm conditions and associatednorm information. In some embodiments, the set of norm conditions may berepresented by an associative array, where a respective key of theassociative array may be a respective norm condition or norm conditionidentifier. The corresponding values of the associative array mayinclude a natural language description of the corresponding conditionand one or more publisher identifiers allowed to indicate that an eventsatisfying the respective norm condition has occurred. In someembodiments, the publisher identifier may indicate a specific entity keyor an entity type. Furthermore, the smart contract may also include orotherwise be associated with a set of norm vertices or a set of graphedges connecting the vertices, as further described below.

In some embodiments, the process 100 includes deserializing a serializedarray of norm vertices to generate a deserialized directed graph, asindicated by block 112. In some embodiments, the smart contract mayinclude or otherwise be associated with a set of norm vertices encodedas a serialized graph in various data serialization formats, where thesmart contract may encode a part or all the norm vertices by encodingthe graph edges connecting the norm vertices The serialized graph mayinclude a representation of an array of subarrays. A data serializationformat may include non-hierarchical formats or flat-file formats, andmay be stored in a persistent storage. In some embodiments, a serializedarray of norm vertices may include numeral values, strings, strings ofbytes, or the like. For example, the array of norm vertices (or otherdata structures in program state) may be stored in a data serializationformat such as JSON, XML, YAML, XDR, property list format, HDF, netCDF,or the like. For example, an array may be decomposed into lists ordictionaries in JSON amenable to serialization. Each subarray of anarray of subarrays may include a pair of norm vertices representing adirected graph edge. For example, a subarray may include a first valueand a second value, where the first value may represent a tail vertex ofa directed graph edge, and where the second value may represent a headvertex of the directed graph edge. For example, a subarray may includethe value “[1,5]” where the first value “1” represents a tail vertexindicated by the index value “1” and “5” represents a head vertexindicated by the index value “5.” While in serialized form, the array ofnorm vertices may reduce memory requirements during data storageoperations and bandwidth requirements during data transfer operations.

In some embodiments, the serialized array of norm vertices may be usedto construct an adjacency matrix or an index-free adjacency list torepresent a deserialized directed graph during a deserializationoperation. In some embodiments, an adjacency matrix or adjacency listmay increase efficient graph rendering or computation operations. Insome embodiments, the deserialized directed graph may be stored in afaster layer of memory relative to the serialized graph, such as in anon-persistent memory layer. For example, the system may deserialize aserialized array of vertices stored in flash memory to a deserializeddirected graph stored in Level 3 cache. In some embodiments, as furtherdescribed below, instead of forming a directed graph that includes allof the norm vertices included in the serialized array of norm vertices,the system may instead form a directed graph from a subset of theserialized array of norm vertices. As described above, each norm vertexmay have an associated norm status indicating whether the norm vertex istriggerable. In response, the system may form a directed graph of thetriggerable vertices without rendering or otherwise processing one ormore norm vertices not indicated to be triggerable. Using this method, avertex that is included in the serialized array of vertices may beabsent in the directed graph stored in non-persistent memory. Byreducing the number of number of vertices in a deserialized directedgraph, the efficiency of querying and updating operations of the smartcontract may be increased.

In some embodiments, the system may include an initial set of normvertices that is distinct from the array of norm vertices. For example,some embodiments may determine that the smart contract had made a firstdetermination that an event had occurred. In some embodiments, thesystem may search the data associated with the smart contract to find aninitial set of norm vertices representing an initial state of the smartcontract. The system may then deserialize the initial set of normvertices when executing the smart contract and perform the operationsfurther described below. The system may then deserialize a differentarray of norm vertices during subsequent deserialization operations.

In some embodiments, the process 100 includes determining a set oftriggerable vertices based on the directed graph, as indicated by block120. In some embodiments, the system may determine the set oftriggerable vertices based on the directed graph stored innon-persistent memory by searching through the vertices of the directedgraph for each of the head vertices of the directed graph and assigningthese vertices as a set of head vertices. The system may then searchthrough the set of head vertices and filter out all head vertices thatare also tail vertices of the directed graph, where the remainingvertices may be the set of leaf vertices of the directed graph, whereeach of the leaf vertices represent a triggerable vertex. Thus, the setof leaf vertices determined may be used as the set of triggerablevertices.

Alternatively, in some embodiments, a vertex of the set of norm verticesmay include or otherwise be associated with a norm status indicatingwhether the vertex is triggerable or not. In some embodiments, thesystem may search through the directed graph for vertices that have anassociated norm status indicating that the respective vertex istriggerable. Alternatively, or in addition, the system may searchthrough a list of norm statuses associated with the vertices of theserialized array of norm vertices to determine which of the vertices istriggerable and determine the set of triggerable vertices. For example,in some embodiments, each norm vertex of a smart contract may have anassociated norm status indicating whether the vertex is triggerable ornot triggerable, where the vertices and their associated statuses may becollected into a map of vertex trigger states. The system may thenperform operations to traverse the map of vertex trigger states anddetermine the set of triggerable vertices by collecting the verticesassociated with a norm status indicating that the vertex is triggerable(e.g. with a boolean value, a numeric value, a string, or the like). Forexample, the system may perform operations represented by Statement 4below, where G may represent a graph and may be an array of subarrays g,where each subarray g may represent a norm vertex and may include a setof values that include the value assigned to the subarray element g[4],where the subarray element g[4] indicates a norm status, and “Active”indicates that the norm vertex associated with subarray g istriggerable, and A is the set of triggerable vertices:

A←{g∈G|g[4]=“Active”}  (4)

In some embodiments, the process 100 includes determining a set oftriggered vertices based on the set of triggerable vertices, asindicated by block 124. In some embodiments, the system may comparedetermine the set of triggered vertices based on which the normconditions associated with the vertices of the directed graph aresatisfied by the event. In some embodiments, a norm condition maydirectly include satisfying event. For example, a norm condition mayinclude “IF DELIVERED(PAYMENT),” where the function “DELIVERED” returnsa boolean value indicating whether a payment represented by the variable“PAYMENT” is true or false. The system may then determine that the normcondition is satisfied if “DELIVERED(PAYMENT)” returns the boolean value“True.” The system may then add the vertex associated with the normcondition to the set of triggered vertices. For example, the system mayperform operations represented by Statement 5 below, where “A” is theset of triggerable vertices determined above, and where each subarray“a” may represent a triggerable vertex and may include a set of valuesthat include the value assigned to the subarray element a[1], where thesubarray element a[1] indicates a condition, and “U” is the set oftriggered vertices, and “N” is an associative array that describes thepossible graph nodes that may be triggered, such that, for an eventprop, N[prop] may return a structure that contains defining details ofthe vertices associated with the event prop:

U←{a∈A|N[a[1]][prop]=E[prop]}  (5)

In some embodiments, the determination that an event satisfies a normcondition may be based on a categorization of a norm into logicalcategories. As further described below in FIG. 5, logical categories mayinclude values such as a “right,” “obligation,” “prohibition,”“permission,” or the like. In some embodiments, after a determinationthat an event triggers a norm condition, the generation of consequentnorms or norm status changes associated with a triggered vertex may bebased on the logical category.

In some embodiments, a snapshot contract status may be associated withthe smart contract and may be used to indicate a general state of thesmart contract. The snapshot contract status may indicate whether theobligations of a contract are being fulfilled or if any prohibitions ofthe contract are being violated. For example, in some embodiments,satisfying an obligation norm condition may result in an increase in thesnapshot contract status and triggering a prohibitions norm may resultin a negative change to the snapshot contract status.

In some embodiments, the process 100 includes performing one or moreoperations indicated by blocks 152, 154, 156, and 160 for each of therespective triggered vertex of the set of triggered vertices, asindicated by block 150. In some embodiments, the process 100 includesupdating the respective triggered vertex based on an event by updating anorm status associated with the respective triggered vertex, asindicated by block 152. Updating a respective triggered vertex mayinclude updating one or more norm statuses or other status valuesassociated with the respective triggered vertex. For example, a normstatus of the respective triggered vertex may be updated to include oneof the strings “SATISFIED,” “EXERCISED,” “FAILED,” or “CANCELED,” basedon the norm conditions associated with the respective triggered vertexhaving been satisfied, exercised, failed, or canceled, respectively. Insome embodiments, the system may update a norm status to indicate thatthe respective triggered vertex is not triggerable. For example, anobligation norm of a smart contract may be required to be satisfied onlyonce. In response, after determining that the norm condition associatedwith the obligation has been satisfied by an event, the system mayupdate a first status value associated with the respective triggeredvertex to “false,” where the first status value indicates whether therespective triggered vertex is triggerable. In some embodiments, the oneor more status values may include a valence value indicating the numberof connections from the respective triggered vertex to another vertices,the number of connections to the respective triggered vertex from othervertices, or the like. As further described below, in some embodiments,the valence value or other status value associated with the respectivetriggered vertex may be updated after performing operations associatedwith the adjacent vertices of the respective triggered vertex.

In some embodiments, the process 100 includes determining whether arespective adjacent vertex of the respective triggered vertex should beset to be triggerable, as indicated by block 154. In some embodiments,the respective triggered vertex may include a pointer to or otherwise beassociated with a set of adjacent vertices, where each of the set ofadjacent vertices represent a norm of the smart contract that are set tooccur after the respective triggered vertex is triggered. In someembodiments, the system may determine whether an adjacent vertex of arespective triggered vertex should be set as triggerable based onspecific conditions associated with the adjacent vertex. For example, arespective triggered vertex may include program code instructing that afirst set of adjacent vertices should be set to be triggerable if afirst set of conditions are satisfied and that a second set of adjacentvertices should be set to be triggerable if a second set of conditionsare satisfied, where the first set of adjacent vertices are distinctfrom the second set of adjacent vertices. Alternatively, or in addition,the respective triggered vertex may include program instructing that athird set of adjacent vertices should be set to be triggerable if thefirst set of conditions are not satisfied but an associated conditionexpiration threshold is satisfied.

In some embodiments, the process 100 includes updating the respectiveadjacent vertex based on the event, as indicated by block 156. Updatingthe respective adjacent vertex based on the event may include settingone or more norm statuses associated with the adjacent vertex toindicate that the respective adjacent vertex is triggerable. Forexample, after a determination that a respective adjacent vertexassociated with a permission norm is to be set to be triggerable, a normstatus associated with the respective adjacent vertex may be updated tothe value “triggerable.”

In some embodiments, the process 100 includes determining whether anyadditional triggered vertices are available, as indicated by block 160.In some embodiments, the system may determine that additional triggeredvertices are available based on a determination that an iterative loopused to cycle through each the triggered vertices has not reached atermination condition. In response to a determination that additionaltriggered vertices are available, the process 100 may return to theoperations of block 150. Otherwise, operations of the process 100 mayproceed to block 164.

In some embodiments, the process 100 includes updating the directedgraph based on the updated triggered vertices or the respective adjacentvertices, as indicated by block 170. In some embodiments, updating thedirected graph may include updating an adjacency matrix or adjacencylist representing the directed based on each of the triggered verticesor their respective adjacent vertices. In some embodiments, instead oflooping through each updated vertex and then updating the directedgraph, the system may update the directed graph during or after eachupdate cycle. For example, after updating the respective triggeredvertex as described in block 156, the system may update the deserializeddirected graph.

In some embodiments, the process 100 includes updating the serializedarray of norm vertices or other smart contract state data based on thedirected graph and updated vertices, as indicated by block 174. In someembodiments, updating the serialized array of norm vertices may includeserializing the directed graph into a data serialization format, asdescribed above. In some embodiments, the data serialization format maybe the same as the data serialization format used when performingoperations described for block 112. For example, the system mayimplement a depth-first search (DFS) over the deserialized directedgraph to record distinct edge pairs and update the serialized array ofnorm vertices by either modifying or replacing the serialized array ofnorm vertices.

In some embodiments, the system may update a knowledge set based on theevent and smart contract state changes that occurred in response to theevent. In some embodiments, the knowledge set may include a set ofprevious events. The set of previous events may be encoded as a list ofprevious events. The list of previous events may include a subarray,where each subarray includes an event identifier of a recorded event orinformation associated with the recorded event. For example, the list ofprevious events may include a date and time during which an eventoccurred, an event identifier, one or more norm conditions satisfied bythe event, or the like. In some embodiments, a norm condition may bebased on the list of previous events. For example, a norm condition mayinclude a determination of whether an event type had occurred twicewithin a time duration based on the list of previous events. In someembodiments, the knowledge set may include a set of previously-triggeredvertices, where the set of previously-triggered vertices may be encodedas an array of previously-triggered vertices. In some embodiments, thesystem may further update the knowledge set by updating the array ofpreviously-triggered vertices based on the triggered vertices describedabove. For example, after updating a respective triggered vertex asdescribed above, the system may update the array of previously-triggeredvertices to include the respective triggered vertex. The array ofpreviously-triggered vertices may include a vertex identifier associatedwith the respective triggered vertex, an event identifier associatedwith the event that triggered the respective triggered vertex, and a setof values identifying the vertices that are set to be triggerable aftertriggering the respective triggered vertex.

In some embodiments, the process 100 includes persisting the updatedserialized array of norm vertices or other smart contract data tostorage, as indicated by block 178. In some embodiments, persisting thesmart contract data to storage may include updating the memory storagein a single computing device or a computing device of a centralizedcomputing system. Alternatively, or in addition, persisting the smartcontract data to storage may include storing the smart contract data toa decentralized tamper-evident data store. In some embodiments, bystoring the serialized array of norm vertices in a decentralizedtamper-evident data store instead of storing a deserialized directedgraph in the decentralized tamper-evident data store, the system mayincrease the efficiency and performance of the data distribution amongstthe nodes of the decentralized tamper-evident data store. Furthermore,in some embodiments, triggering a norm vertex may include triggering asmart contract termination action. When a smart contract terminationaction is triggered, vertices other than the respective triggered vertexmay be updated to set the statuses of each vertex of these othervertices as not triggerable, even if these other vertices are notdirectly connected to the triggered vertex.

In some embodiments, the system may display a visualization of the smartcontract state. For example, the system may display a visualization ofsmart contract state as a directed graph, such as (though not limitedto) those shown in FIGS. 5-10 below, where the vertices may havedifferent colors based on norm status and/or logical category.Alternatively, or in addition, the system may generate other types ofvisualizations of the smart contract state. For example, the system maydisplay a pie chart representing of a plurality of smart contract typesthat indicate which type of the smart contracts have the highest amountof associated cost.

In some embodiments, the process 100 or other processes described inthis disclosure may execute on a decentralized computing platformcapable of persisting state to a decentralized tamper-evident datastore. Furthermore, in some embodiments, the decentralized computingplatform may be capable of executing various programs, such as smartcontracts, on the computing platform in a decentralized, verifiablemanner. For example, each of a set of peer nodes of the computingplatform may perform the same computations, and a consensus may bereached regarding results of the computation. In some embodiments,various consensus algorithms (e.g., Raft, Paxos, Helix, Hotstuff,Practical Byzantine Fault Tolerance, Honey Badger Byzantine FaultTolerance, or the like) may be implemented to determine states orcomputation results of the various programs executed on thedecentralized computing platform without requiring that any onecomputing device be a trusted device (e.g., require an assumption thatthe computing device's computation results are correct). The one or moreconsensus algorithms used may be selected or altered to impede an entityfrom modifying, corrupting, or otherwise altering results of thecomputation by peer nodes not under the entity's control. Examples of adecentralized tamper-evident data store may include Interplanetary FileSystem, Blockstack, Swarm, or the like. Examples of a decentralizedcomputing platform may include Hyperledger (e.g., Sawtooth, Fabric, orIroha, or the like), Stellar, Ethereum, EOS, Bitcoin, Corda, Libra, NEO,or Openchain.

FIG. 2 depicts a data model of program state data, in accordance withsome embodiments of the present techniques. In some embodiments, a smartcontract may include or otherwise be associated with program state datasuch as smart contract state data 200. The smart contract state data 200includes an associative array of entities 210, an associative array ofconditions 220, an associative array of norms 230, a graph list 240, anda knowledge list 250. The associative array of entities 210 may includea set of keys, each key representing an entity capable of interactingwith or observing smart contract data. For example, a publisherproviding an event message to the smart contract may be an entity. Thecorresponding value of a key of the associative array of entities 210may include a submap that includes values for a name, a legal identifiervalue (e.g., a ISIN/CUSIP identifier), an entity type for authorizationoperations, and a public key for authentication operations (e.g., acryptographic public key). In some embodiments, the name, identifiervalue, entity type, or public keys may be used in the authorization andauthentication operations discussed for block 104.

The associative array of conditions 220 may include a set of keys, whereeach key represents an event that may trigger at least one triggerablevertex that would result in a change in norm status, and where acorresponding value of each key includes an events submap. The eventssubmap may include a publisher identifier. As shown by the link 221, thepublisher identifier may be used as a reference to the key of theassociative array of entities. Alternatively, or in addition, the eventssubmap may include a subject identifier, which may include natural textlanguage to provide a context for the corresponding event.

The associative array of norms 230 may include a set of keys, where eachkey may represent a norm of the smart contract, which may be associatedwith as a norm vertex in a graph, norm conditions and consequent norms.In some embodiments, the consequent norms may themselves be associatedwith their own norm vertices. Each value corresponding to the norm mayinclude a norms submap that includes one or more norm conditions thatmay be used to trigger the norm by satisfying a norm condition, or bynot satisfying the norm condition after satisfying condition expirationthreshold associated with the norm. As shown by the link 231, the normconditions may include a norm identifier that may be used as a referenceto a key of the associative array of conditions 220. The norms submapmay also include an entity identifier, where the entity identifier maybe used as reference to a key of the associative array of entities 210,as shown by the link 232. The norm may also include a conditionexpiration threshold, which may be represented by the “expiry” fieldshown in the associative array of norms 230. As discussed above, someembodiments may result in a norm status change or trigger other updatesto a vertex if a norm condition is not satisfied but the conditionexpiration threshold is satisfied. The norm submap may also include aconsequences list, where the consequences list may include set ofsublists that includes a tail vertex representing a consequent norm thatbecome triggerable, a head vertex of the new norm (which may be thetriggered norm), and a label.

In some embodiments, a smart contract state may initially construct thegraph list 240 in a first iteration based on the associative array ofnorms 230 and update the graph list 240 based on a previous iteration ofthe graph list 240. As described above, the graph list may be in aserialized form, such as a serialized array of norm vertices written inthe YAML markup language. As discussed above, the graph list 240 may bea list of graph sublists, where each sublist includes a tail vertexvalue, a head vertex value, a label associated with the graph edgeconnecting the tail vertex with the head vertex, a group identifier, anda norm status value. In some embodiments, the norm status may includevalues such as “satisfied,” “exercised,” “failed,” “active,” “terminal,”“canceled,” “triggerable,” or “untriggerable.” In some embodiments, anorm vertex may be associated with more than one norm status. As shownby link 241, a tail vertex of the graph may be linked to a norm in theassociative array of norms 230. Similarly, as shown by the links242-243, the tail and head vertices of the graph list 240 may beassociated with a listed tail norm or head norm in the associative arrayof norms 230 for a respective norm. Furthermore, as shown by the link244, the group identifier listed in a graph sublist may also beassociated with a value in the associative array of norms 230, such aswith a key in the associative array of norms 230.

In some embodiments, a smart contract state may initially construct theknowledge list 250 in a first iteration based on the associative arrayof norms 230 and update the knowledge list 250 based on smart contractstate changes. The knowledge list 250 may be sequentially ordered intime (e.g. a time when a norm status changes, a time when an event isreceived, or the like). In some embodiments, each entry of the knowledgelist 250 may include an identifier “eid,” an event time “etime,” apublisher identifier associated with an event that triggered a normvertex, the event that triggered the norm vertex. In addition, theknowledge list 250 may include various other data related to the smartcontract state change, such as a field “negation” to indicate whether anevent is negated, a field “ptime” in ISO8601 format to represent ansub-event time (e.g. for event that require multiple sub-events totrigger a norm vertex), a field “signature” to provide a signature valuethat allows authentication against the public key held by a publisherfor later data authentication operations or data forensics operations.In some embodiments, the knowledge list 250 may include an evidencelist, where the evidence list may include a base64 encoded blob, anevidence type containing a string describing the file type of thedecoded evidence, and a field for descriptive purposes. In someembodiments, the evidence list may be used for additional safety orverification during transactions.

As described above, some embodiments may efficiently store or updateprogram state data using a set of serialization or deserializationoperations. Some embodiments may assign outcome scores to possibleoutcomes of an update operation, which may then be used to predictfuture states of a program. Some embodiments may perform operations,such as those described further below, to predict an outcome score usingdata encoded in a directed graph with greater efficiency or accuracy.

Graph Outcome Determination in Domain-Specific Execution Environment

In some embodiments, outcomes of symbolic AI models (like thetechnology-based self-executing protocols discussed in this disclosure,expert systems, and others) may be simulated and characterized invarious ways that are useful for understanding complex systems. Examplesof symbolic AI systems include systems that may determine a set ofoutputs from a set of inputs using one or more lookup tables, graphs(e.g. a decision tree), logical systems, or other interpretable AIsystems (which may include non-interpretable sub-components or bepipelined with non-interpretable models). The data models, norms, orother elements described in this disclosure constitute an example of asymbolic AI model. Some embodiments may use a symbolic AI model (like aset of smart contracts) in order to predict possible outcomes of themodel and determine associated probability distributions for the set ofpossible outcomes (or various population statistics). Features of asymbolic AI model that incorporates elements of data model described inthis disclosure may increase the efficiency of smart contract searches.In addition, the use of logical categories (e.g., “right,” “permission,”“obligation”) describing the relationships between conditionalstatements (or other logical units) of a smart contract may allow theaccurate prediction of (or sampling of) outcomes across a population ofdifferently-structured smart contracts without requiring atime-consuming analysis of each of the contexts of individual smartcontracts from the population of differently-structured smart contracts.Furthermore, the operations of a symbolic AI model may be used topredict outcomes (e.g., of a smart contract, or call graph of such smartcontracts) and may be tracked to logical units (like conditionalstatements, such as rules of a smart contract). These predicted outcomesmay be explainable to an external observer in the context of the termsof the logical units of symbolic AI models, which may be useful inmedical fields, legal fields, robotics, dev ops, financial fields, orother fields of industry or research.

In some embodiments, the symbolic AI model may include the use of scoresfor a single smart contract or a plurality of smart contracts, where thescore may represent various values, like a range of movement along adegree of freedom of an industrial robot, an amount of computer memoryto be allocated, an amount of processing time that a first entity owes asecond entity, an amount to be changed between two entities, a totalamount stored by an entity, or the like. A symbolic AI model may includescores of different type. Changes in scores of different type may occurconcurrently when modeling an interaction between different entities.For example, a first score type may represent an amount of computermemory to be stored within a first duration and a second score type mayrepresent an amount of computer memory to stored within a secondduration that occurs after the first duration. A smart contract may beused to allocate computer memory across two different entities tooptimize memory use across the entity domains. Possible outcomes andwith respect to memory allocation across the two domains may besimulated. Alternatively, or in addition, exchanges in other computingresources of the same type or different types may be simulated withscores in a symbolic AI model. For example, a symbolic AI model mayinclude a first score and as second score, where the first score mayrepresent an amount of bandwidth available for communication between afirst entity or second entity and a third entity, and where the secondscore may represent an amount of memory available for use by the firstor second entity. The outcome of an exchange negotiated via a smartcontract between the first and second entity for bandwidth and memoryallocation may then be simulated to predict wireless computing resourcedistribution during operations of a distributed data structure across awireless network or other computing operations.

In some embodiments, simulating outcomes of may include processing oneor more norm vertices representing one or more norms of a smart contractas described in this disclosure. For example, the symbolic AI model mayinclude an object representing a norm vertex, where the object includesa first score representing an amount owed to a first entity and a secondscore representing an amount that would be automatically transferred tothe first entity (e.g., as a down payment). In some embodiments, thesymbolic AI model may incorporate the entirety of a smart contract andits associated data model when performing simulations based on the smartcontract. For example, a symbolic AI model may include one or moredirected graphs of to represent the state of a data model.Alternatively, or in addition, some embodiments may include more datathan the smart contract being simulated or less data than the smartcontract be simulated.

In some embodiments, the symbolic AI system (a term used interchangeablywith symbolic AI model) may process the conditional statements (or otherlogical units) associated with each of the norms of a smart contract toincrease simulation efficiency by extracting only quantitative changesand making simplifying assumptions about score changes. For example, asystem may collect the norm conditions and associated outcomesubroutines associated with each of a set of norm vertices and extractonly the changes in an amount of currency owed as a first score andchanges in an amount of currency transferred as a seconds score whenincorporating this information into the conditions of the symbolic AImodel. In some embodiments, the information reduction may increasecomputation efficiency by removing information from the analysis of asmart contract determined to be not pertinent to a selected score. Someembodiments simulate outcomes across a plurality of smart contractsusing a standardized search and simulation heuristic, and the systemdescribed herein may provide a population of scores, where thepopulation of scores may be the plurality of outcome scores determinedfrom a simulation of each of the smart contracts or values computed fromthe plurality of outcome scores. For example, values determined based onthe population of scores may include parameters of a probabilitydistribution of the scores, a total score value, a measure of centraltendency (e.g. median score value, mean score value, etc.), or the like.

In some embodiments, the symbolic AI model may be an un-instantiatedsmart contract or may be a transformation thereof, e.g., approximatingthe smart contract. For example, as further described below, the systemmay instantiate a program instance that includes a symbolic AI modelbased on a selected smart contract that is not yet instantiated.Alternatively, a symbolic AI model may be determined based on aninstantiated smart contract. For example, the system may select aninstantiated smart contract with a program state that has alreadychanged from its initial program state in order to determine futurepossible outcomes in the context of the existing changes. The system maythen copy or otherwise use a simulated version of the changed programstate when simulating the instantiated smart contract. For example, thesystem may select an instantiated smart contract for simulation with asymbolic AI system and deserialize a directed graph of the instantiatedsmart contract. The symbolic AI system may copy the deserializeddirected graph to generate a simulation of the directed graph, where thenodes of the simulated directed graph are associated with simplifiedconditional statements that convert quantifiable changes into scores andare stripped of non-quantifiable changes in comparison to theconditional statements of the smart contract.

FIG. 3 is flowchart of an example of a process by which a program maysimulate outcomes or outcome scores of symbolic AI models, in accordancewith some embodiments of the present techniques. In some embodiments, aprocess 300 includes selecting a set of smart contracts (or othersymbolic AI models) based on a search parameter, as indicated by block304. In some embodiments, a system may include or otherwise have accessto a plurality of smart contracts or smart contract instances, and thesystem may select a set of smart contracts from the plurality based on aspecific search parameter, such as an entity, entity type, event, eventtype, or keyword. For example, the system may perform a lookup operationto select which of the smart contracts to access based an event. Duringthe lookup operation, the system may compare an event to the associativearrays of conditions corresponding to each of a plurality of smartcontracts and select a set of smart contracts based on which of thesmart contracts would change state in response to receiving the event.Some embodiments may crawl a call graph (of calls between smartcontracts, or other symbolic AI models) to select additional smartcontracts.

In addition, or alternatively, the system may perform a lookup operationto select which of the smart contracts to access based on an entity orentity type. For example, the system may compare an entity to theassociative arrays of entities corresponding to each of a plurality ofsmart contracts and select a set of smart contracts based on which ofthe corresponding arrays of entities include the entity. An entityidentifier may be in an array of entities or some other set of entitiesif an entity type associated with the entity identifier is in the arrayof entities. For example, if the entity “BLMBRG” has an associatedentity type of “trusted publisher,” some embodiments may determine that“BLMBRG” is in the set of entities of a smart contract if the entitytype “trusted publisher” is listed in the set of entities.Alternatively, some embodiments may require that the exact entityidentifier be listed in a set of entities before determining that theentity identifier in the set of entities. For example, some embodimentsmay determine that “BLMBRG” is in a set of entities of a smart contractonly if “BLMBRG” is one of the elements of the set of entities.Furthermore, in some embodiments, the search may include intermediaryentities between two different entities, where intermediary smartcontract may be a smart contract (other than the first or second smartcontract) that has relationships with both the first and secondentities. For example, a search for smart contracts relating a firstentity and a second entity may return a set smart contracts that includea first smart contract and a second smart contract, where the array ofentities of the first smart contract includes the first entity and anintermediary entity, and where the array of entities of the second smartcontract includes the second entity and the intermediary entity.

In some embodiments, an intermediary entity for a first entity and asecond entity may be found by determining the intersection of entitiesbetween a first set of smart contracts associated with the first entityand a second set of smart contracts associated with the second entity.For example, the system may select a first set of smart contracts from aplurality of smart contracts based on which sets of entities associatedwith plurality of smart contracts include the first entity. Similarly,the system may select a second set of smart contracts from a pluralityof smart contracts based on which sets of entities associated withplurality of smart contracts include the second entity. The system maythen determine the intersection of entities by searching through thesets of entities of the first and second set of smart contracts tocollect the entities that appear in both the first set and second setand determine that these collected entities are intermediary entities.In some embodiments, as further described below, additional methods arepossible to determine a set of smart contracts associating a firstentity with a second entity in order to quantify a relationship betweenthe first entity and the second entity.

As discussed in this disclosure, some embodiments may crawl a call graphto select additional smart contracts based on possible relationshipsbetween a first entity and a second entity. The call graph may be aprivity graph, which may track privity relations between the firstentity and entities other than the second entity in order to determineor quantify relations between the first entity and the second entity. ifFor example, some embodiments may crawl through a privity graph ofpossible score changes across multiple contracts and determine aquantitative score relationship between a first entity and a secondentity based on a first transaction between the first entity and a thirdentity, a second transaction between the third entity and a fourthentity, a third transaction between the fourth entity and a fifthentity, and a fourth transaction between the fifth entity and the secondentity.

In some embodiments, the process 300 includes performing one or moreoperations indicated by blocks 312, 316, 320, 324, 328, 336, 340, 344,and 350 for each of the respective smart contracts or other programs ofthe selected set of smart contracts or other programs, as indicated byblock 308. As further discussed below, the one or more outputs fromexecuting each of the smart contracts may be used to determine apopulation of scores of multiple smart contracts. As used herein, thepopulation of scores of multiple smart contracts may represent one ormore population metric values calculated from scores of the smartcontract. For example, the population of scores of multiple smartcontracts may include a measure of central tendency, a measure ofdispersion, a kurtosis value, a parameter of a statistical distribution,one or more values of histogram, or the like. Furthermore, in someembodiments, the process 300 may include performing one or moreoperations in parallel using multiple processor cores, where performingmultiple operations in parallel may include performing the multipleoperations concurrently. For example, some embodiments may perform theoperations of the blocks 312, 316, 320, 324, 328, 336, 340, 344, and 350for a plurality of smart contracts in parallel by using one or moreprocessors for each of the plurality of smart contracts. By performingoperations in parallel, computation times may be significantly reduced.

In some embodiments, the process 300 includes acquiring a set ofconditional statements (or other logical units), set of entities, set ofindices indexing the conditional statements, or other data associatedwith the selected smart contract, as indicated by block 312. Each of theset of conditional statements may be associated with an index value andmay include or be otherwise associated with a respective set ofconditions and a respective set of outcome subroutines, where acomputing device may execute the respective set of outcome subroutinesin response to an event satisfying the respective set of conditions. Insome embodiments, the set of conditional statements may form a network,like a tree structure, with respect to each other. For example, anoutcome subroutine of one the conditional statements may include areference to or otherwise use an index value associated with anotherconditional statement. In some embodiments, the set of conditionalstatements and set of indices may be acquired from a data model, wherethe index values may be or otherwise correspond to the identifiers fornorm vertices of a directed graph. For example, the set of conditionalstatements and set of indices may be acquired from the associative arrayof norms 230, the associative array of conditions 220, and the graphlist 240. Alternatively, the system may acquire the conditionalstatements and indices from data stored using other data models. Forexample, the system may acquire the conditional statements from anindexed array of objects, where each object may include a method thatcan take an event as a parameter, test the event based on a condition ofthe method, and return a set of values or include a reference to anotherobject of the array. The system may use the indices of the indexed arrayas the indices of the conditional statements and parse the methods toprovide the set of conditional statements.

In some embodiments, the process 300 includes instantiating or otherwiseexecuting a program instance having program state data that includes asymbolic AI model that includes values from the data associated with theselected smart contract, as indicated by block 316. In some embodiments,the symbolic AI model may include graph vertices associated with the setof conditional statements described in this disclosure and may alsoinclude directed graph edges connecting the graph vertices. In addition,or alternatively, the symbolic AI model may include a set of tables,decision trees, graphs, or logical systems to provide a predicted valueas an output based on one or more inputs corresponding to real orsimulated events. For example, the system may traverse the directedgraph of a symbolic AI model to determine which nodes of the directedgraph to visit based on a decision tree of the symbolic AI model.Furthermore, in some embodiments, the symbolic AI system may bere-instantiated or be modified in real-time in response to a particularevent message updating a smart contract being simulated. For example, aninstantiated smart contract may be executing and concurrently beingsimulated by a symbolic AI system. In response to the smart contractreceiving an event message, the symbolic AI system may determine a newset of events based on the event message and update its own programstate such that its new initial state is based on the smart contractprogram state after the smart contract program state has been updated bythe events of the event message.

In some embodiments, the symbolic AI model may include a graph. In someembodiments, the system may generate a graph list such as the graph list240 using the methods discussed in this disclosure. In some embodiments,the program instance may be a local version of a selected smart contractand have program state data identical to program state data in theselected smart contract. Alternatively, the program instance may includeprogram data not included in the smart contract or exclude data includedin the smart contract. In some embodiments, the graph of the symbolic AImodel may include a set of graph vertices and a set of directed graphedges connecting the graph vertices, where each of the graph verticesmay be identified by an identifier and corresponds to a conditionalstatement of a smart contract. In some embodiments, the identifier maybe the set of index values associated with the conditional statements ofthe smart contract. Alternatively, the identifier may be different fromthe set of index values associated with the conditional statements ofthe smart contract. For example, the system may choose a set ofidentifiers that are different from the set of index values to increasesystem efficiency or reduce memory use.

In some embodiments, the directed graph edges may be structured toprovide directional information about the graph vertices of a symbolicAI model. For example, a directed graph edge may be represented as anarray of identifier pairs. The first element of each of the identifierpairs may be treated as a tail vertex by the symbolic AI system and thesecond element of the identifier pairs may be treated as a head vertexby the symbolic AI system. In some embodiments, the selected smartcontract may already be in the process of being executed and the programstate data of the program instance may include the norm statuses andscores of the smart contract state. For example, the program state datamay be copied directly from the state data of a selected smart contract,where the changes effected by the outcome subroutines may be treated asscores.

A smart contract score may represent one of various types of values. Forexample, a smart contract score may represent a reputation score of anentity in a social network, a cryptocurrency value such as an amount ofcryptocurrency, an amount of electrical energy, an amount of computingeffort such as Ethereum's Gas, an amount of computing memory, or thelike. A smart contract score may represent an objective value associatedwith an entity, such as an available amount of computing memoryassociated with the entity. Alternatively, a smart contract score mayrepresent an amount by which a stored value is to be changed, such as acredit amount transferred from a first entity to a second entity.

In some embodiments, a program state may keep track of a plurality ofscores. For example, a vertex of a directed graph of a symbolic AI modelmay include or otherwise be associated with a first score representingan amount of possessed by a first entity, a second score representing anamount owed to or owed by the first entity, a third score representingan amount possessed by a second entity, and a fourth score representingan amount owed to or owed by the second entity. In some embodiments, aconditional statement may be parsed to determine outcome scores. Forexample, an outcome subroutine associated with a vertex of a graph ofthe symbolic AI model may include instructions that a first entity isobligated provide 30 cryptocurrency units to a second entity and thatthe second entity is obligated to send a message to the first entitywith an electronic receipt, and the system may determine that anassociated score of the first vertex is equal to 30 and also determinethat no score value is needed for the sending of the message. As furtherdiscussed below, by keeping track of scores and score changes, entirepopulations of smart contracts may be analyzed with greater accuracywithout requiring a deep understanding of the specific terms or entitybehaviors of any specific contract.

In some embodiments, a symbolic AI model may include statusescorresponding to each of a set of vertices representing the norms of asmart contract. The symbolic AI model statuses may use the samecategories as the norm statuses of a smart contract. Furthermore, thesymbolic AI model status for a vertex may be identical to or beotherwise based on the status for the corresponding norm vertex beingsimulated. For example, if a norm status for a first norm vertex of asmart contract is “triggered—satisfied,” the symbolic AI model statusfor a first symbolic AI model vertex corresponding to the first normvertex may also be “triggered—satisfied.” Alternatively, the system mayselect a different categorical value for a symbolic AI model vertexstatus that is still based on the corresponding norm status. Similarly,the symbolic AI model may include vertex categories similar to oridentical to the logical categories associated with of the set of normvertices of a smart contract. Furthermore, the symbolic AI model vertexcategory may be identical to or be otherwise based on the logical forthe corresponding norm vertex being simulated. For example, if a logicalcategory for a first norm vertex of a smart contract is “Rights” thesymbolic AI model category for a first symbolic AI model vertex (“vertexcategory”) corresponding to the first norm vertex may also be “Rights.”Alternatively, the system may select a different categorical value for avertex category that is still based on the corresponding logicalcategory.

In some embodiments, the instantiated program may be a smart contractthat may use or otherwise process events. Alternatively, or in addition,the program instance may be a modeling application and not an instanceof the selected smart contract itself. For example, a symbolic AI systemmay be a modeling application that determines the values of acorresponding symbolic AI model based on the conditional statements of asmart contract without requiring that an event message be sent to an APIof the modeling application. In some embodiments, the program instanceof the symbolic AI system may change program state without performingone or more operations used by the smart contract that the programinstance is based on. For example, the program instance of the symbolicAI system may change its program state data without deserializingserialized smart contract data, even if the smart contract that theprogram instance is based on includes operations to deserializeserialized smart contract data. In some embodiments, the program statedata may be stored using a data model similar to that described in thisdisclosure for FIG. 2. Alternatively, or in addition, the program statedata may be stored in various other ways. For example, instead ofstoring values in separate arrays, the program instance may store thenorm conditions, norm outcome actions, and their relationships to eachother as part of a same array.

In some embodiments, the process 300 includes performing one or moreiterations of the operations indicated by blocks 320, 324, 328, 332,336, and 340 for each of the respective smart contracts or otherprograms of the selected set of smart contracts or other programs, asindicated by block 320. Furthermore, in some embodiments, the process300 may include performing the one or more iterations in parallel usingmultiple processor cores. For example, some embodiments may includeperforming multiple iterations of the operations of the blocks 320, 324,328, 332, 336, or 340 for multiple iterations in parallel using aplurality of processor cores. By performing the multiple iterations ofthe operations in parallel, computation times may be significantlyreduced.

In some embodiments, the system may perform one or more iterations ofoperations to modify the statuses of a first set of vertices and thenupdate the program state data based on the modified statuses in order toacquire a plurality of outcomes. The program state data or a portion ofthe program state data may be in a same state at the start eachiteration, where two states of program state data are identical if bothstates have the same set of values. For example, if a first state ofprogram state data is [1,2,3], and if a second state of program statedata is [1,2,4], and if the program state data is reverted to [1,2,3],the reverted program state data may be described as being in the firststate. In some embodiments, the system may execute the smart contract orsmart contract simulation for a pre-determined number of iterations.Alternatively, or in addition, as further recited below, the smartcontract or smart contract simulation may be repeatedly executed until aset of iteration stopping criteria are achieved. As further discussedbelow, the plurality of outcomes corresponding to the plurality ofiterations may be used to provide one or more multi-iteration scoresusable for decision-support systems and for determining multi-protocolscores.

In some embodiments, the system may modify one or more statusesassociated with the vertices of the graph of the symbolic AI model basedon a scenario and update the program state data based on the modifiedstatuses, as indicated by block 328. In some embodiments, the scenariomay be a set of inputs based on events. For example, a scenario mayinclude simulated events or simulated event messages that may betestable by the conditions of a conditional statement. In response, afirst vertex of the program instance may compare the simulated event toa condition and determine that a second vertex of the symbolic AI modelof the should be activated. For example, an input may include an event“entity A transmitted data 0x104ABC to entity C,” which may satisfy acondition and change a status associated with a first vertex associatedwith the conditional statement to “satisfied.” As discussed below, thesystem may then update the symbolic AI model based on the status changeby activating an adjacent vertex to the first vertex.

Alternatively, or in addition, an input may include a message to changea program state without including an event that satisfies the normconditions associated with the norm. For example, the input may includedirect instructions interpretable by a symbolic AI system to set avertex status to indicate that the corresponding vertex is triggered anddirect which of a set of outcome subroutines to execute. The system maythen update the symbolic AI model by activating one or more adjacentvertices described by the subset of outcome subroutines to execute.

In some embodiments, the scenario may include a single input.Alternatively, the scenario may include a sequence of inputs. Forexample, the scenario may include a first event, second event, and thirdevent in sequential order. In some embodiments, the set of events may begenerated using a Monte Carlo simulator. Some embodiments may randomlydetermine subsequent states from an initial state based on one or moreprobability distributions associated with each state of a set ofpossible subsequent states with respect to a previous state, where theprobability distributions may be based on scores and logical categoriesassociated with the set of possible states. For example, the programstate may be in a state where only two subsequent possible states arepossible, where the first subsequent possible state includes triggeringa rights norm and a second subsequent possible state includes triggeringan obligations norm.

In some embodiments, one or more inputs of a scenario may be determinedusing a decision tree. In some embodiments, a decision tree may be usedto provide a set of decision based on scores, logical categories,statuses, and other factors associated with the active vertices of asimulated smart contract state. For example, a symbolic AI system maydetermine that the two possible states for a smart contract may resultfrom either exercising a first rights norm or exercising of a secondrights norm. A decision tree may be used to compare the logicalcategories, the scores associated with each norm, and the otherinformation related to the active norms to determine which rights norman entity would be most likely to exercise. In some embodiments, thesymbolic AI system may compare a first score associated with a possiblestate represented by a first tree node with a second score of adifferent possible state represented by a second tree node. In responseto the first score being greater than the second score, the symbolic AIsystem may determine a simulated input that will result in the futurestate represented by the first tree node. Furthermore, in someembodiments, the decision tree may incorporate probability distributionsor other decision-influencing factors to more accurately simulatereal-world scenarios.

Alternatively, or in addition, some embodiments may include a MonteCarlo Tree Search (MCTS) method to generate a random sequence of eventsbased on a set of possible events and a probability distribution bywhich the events may occur. The operations of the simulation may be mademore efficient by selecting events that known to satisfy at least onecondition of the set of conditional statements of the smart contractbeing simulated. In some embodiments, a symbolic AI system may determinea set of events for a smart contract simulation by determining a firstsimulated input based on a set of weighting values assigned to verticesof a graph of a symbolic AI model associated with norms of the smartcontract. In some embodiments, the system may further determine asimulated input based on a count of the number of iterations of thesimulation performed so far.

The system may then update the symbolic AI model based on the firstsimulated input, advancing the symbolic AI model to a second state. Forexample, after changing the status of a first vertex associated with anobligations norm from “unrealized” to “failed,” the symbolic AI modelmay then activate a first adjacent vertex representing a rights norm anda second adjacent vertex representing an prohibitions norm, where bothadjacent vertices are adjacent to the first vertex. The symbolic AIsystem may then determine a second simulated input, wherein the secondsimulated input may be selected based on weighting value correspondingto each of the first adjacent vertex and second adjacent vertex, wherethe weighting value may be a score of the smart contract. For example,the weighting value of the first adjacent vertex may be 2/4 and theweighting value of the second adjacent vertex may be 1/6. Someembodiments may then update the symbolic AI model when it is in thesecond state based on the second simulated input in order to advance thesecond model to a terminal state, where a terminal state is one thatsatisfies a terminal state criterion. Once in a terminal state, thesymbolic AI system may update the weighting values associated with thesymbolic AI model before performing another iteration of the simulation.

Various terminal state criteria may be used. For example, a terminalstate criterion may be that there is no further state change possible.Alternatively, a terminal state criterion may be that the smart contractis cancelled. The system may then update each of the weighting valuesassociated with each of the nodes after reaching a terminal state beforeproceeding to perform another iteration. In some embodiments, thesymbolic AI system may set a status of a vertex to “failed” to simulatethe outcomes of a first entity failing to transfer a score (e.g. failureto pay) a second entity.

In some embodiments, the determination of an input may be based on thetype of conditional statement being triggered. As further discussedbelow, one or more of the conditional statements may be non-exclusivelyclassified as one or more types of norms. Example of norm types includerights norms, obligations norms, or prohibition norms. As furtherdiscussed below, norm types may also include associations as being partof a pattern, such as a permission pattern. For example, a vertex mayinclude or be otherwise associated with the label “consent or request.”By determining activities based on logical categories associated withthe conditional statements instead of specific events, predictivemodeling may be performed using globalized behavior rules withoutinterpreting each of the globalized behavior rules for each specificcontract. For example, a sequence of event may be generated a based on afirst probability distribution that approximates an obligation of afirst entity as having a 95% chance of being fulfilled and a 5% chanceof being denied and a second probability distribution that approximatesthat a second entity has a 10% chance of cancelling a smart contractbefore the first entity exercises a right to cure the failure to satisfythe obligation. Using these rules, population scores associated with thepopulation of smart contracts between a first entity and a second entitythat consist of obligations norms to pay, rights norms to cure, andrights norms to cancel may be determined without regards to the specificstructure of individual smart contracts in the population of smartcontracts.

The system may then update each of the smart contract instancesassociated with a changed norm status, as discussed further below.Furthermore, the system may then update the respective associative arrayof conditions corresponding to the set of smart contracts. In someembodiments, an associative array of conditions may include only asubset of norm conditions associated with a smart contract, where eachthe subset of norm conditions is associated with a triggerable vertex ofthe smart contract. In some embodiments, the system may firstdeduplicate the norm conditions before performing a lookup operation toincrease performance efficiency. For example, after determining that anevent has occurred, some embodiments may search through a deduplicatedarray of norm conditions. For each norm condition that the event wouldtrigger, the system may then update the one or more smart contractsassociated with the norm condition in the deduplicated array of normconditions.

Some embodiments may obtain a sequence of inputs instead of a singleinput. In some embodiments, the system may use a neural network togenerate the sequence of inputs. In some embodiments, the neural networkmay determine a state value s based on the program state data andprovide a vector of probabilities associated with for each of a set ofpossible changes in the program state. The neural network may alsodetermine a state value to estimate the expected value of the programstate after system applies the scenario to the program. In someembodiments, the neural network may use a MCTS algorithm to traverse atree representing possible future states of the smart contract from aroot state. The system may determine a next possible state s₊₁ for eachstate s by selecting a state with a low visit count, high predictedstate value, and high probability of selection. The parameters (e.g.weights, biases, etc.) of the neural network making the state valuedetermination may be represented by θ. After each iteration ending in aterminal state, the system may adjust the values θ to increase theaccuracy of the neural network's predicted state value in comparison tothe actual state value assessed whenever a terminal state is reached.Furthermore, a symbolic AI model may have a total score value, and thesystem may update the total score value based on the state value.

In some embodiments, the process 300 includes determining an outcomescore based on the updated program state data, as indicated by block336. In some embodiments, as stated in this disclosure, a set of scoresmay be associated with one or more of the outcome states. For example,an outcome of a first norm may include a transfer of currency valuesfrom a first entity to a second entity. The symbolic AI system mayrecord this score and combine it with other scores in the same iterationin order to determine a net score for that score type. For example, thesymbolic AI system may record each currency change based on inputs andoutcomes in order to determine a net currency change, where a score ofthe smart contract may be the net currency change. Alternatively, or inaddition, the symbolic AI system may record scores across differentiterations to determine a multi-iteration score, as described furtherbelow. Example outcome scores may include a net amount of currencyexchanged, a net amount of computing resources consumed, a change in thetotal cryptocurrency balance for an entity, or the like.

The process 300 may execute a number of iterations of smart contractstate change simulations to determine possible outcomes and outcomescores. In some embodiments, there may be one or more criteria todetermine if an additional iteration is needed, as indicated by block340. In some embodiments, the one or more criteria may include whetheror not a pre-determined number of iterations of simulations have beenexecuted. For example, some embodiments may determine that additionaliterations are needed if the total number of executed iterations is lessthan an iteration threshold, where the iteration threshold may begreater than five iterations, greater than ten iterations, greater than100 iterations, greater than 1000 iteration, greater than one millioniterations, greater than one billion iterations, or the like.Alternatively, or in addition, the one or more criteria may includedetermining whether a specific outcome occurs. For example, the one ormore criteria may include determining whether the outcome score is lessthan zero after a terminal state is reached. If the additionaliterations are needed, operations of the process 300 may return to block320. Otherwise, operations of the process 300 may proceed to block 344.

In some embodiments, the process 300 includes determining amulti-iteration score based on the outcome scores of executediterations, as indicated by block 344. The multi-iteration score may beone of various types of scores and may include values such as a netchange in score across multiple iterations, a probability distributionparameter, a measure of central tendency across multiple iterations, ameasure of dispersion, or a measure of kurtosis. For example, the systemmay use a first outcome score from a first iteration, a second outcomescore from a second iteration, or additional outcome scores fromadditional iterations to determine an average outcome score. The systemmay determine additional multi-iteration scores in the form ofprobability distribution parameters to determine a probabilitydistribution. As used herein, a measure of kurtosis value may becorrelated with a ratio of a first value and a second value, wherein thefirst value is based on a measure of central tendency, and wherein thesecond value is based on a measure of dispersion. For example, themeasure of kurtosis may equal to μ⁴/σ⁴, where μ may be a fourth centralmoment of a probability distribution and a may be a standard deviationof the probability distribution.

In some embodiments, the multi-iteration score may be used to provideone or more predictions using Bayesian inference methods. In someembodiments, the multi-iteration score may be used to generate aprobability distribution for the probability that a particular event orevent type occurred based on a score, such as a change in currency valueor an amount of computing resources consumed. For example, the systemmay calculate a mean average cryptocurrency amount determined acrossmultiple iterations as a first multi-iteration score and a standarddeviation of the cryptocurrency amount as the second multi-iterationscore while tracking the number of payment delays associated with therespective cryptocurrency amounts. The system may then use the first andsecond multi-iteration scores to generate a gaussian distribution, wherethe system may use the gaussian distribution to perform Bayesianinferences in order to determine a probability that a payment delayoccurred after obtaining the value of a new cryptocurrency amount.

In some embodiments, the multi-iteration score may be a weight, bias, orother parameter of a neural network. For example, some embodiments mayuse a set of multi-iteration scores as weights of a neural network,where the training inputs of the neural network may be outcome scoresand the training outputs of the neural network may be events, indicatorsrepresenting activated outcome subroutines, or activated patterns. Oncetrained, the neural network may determine the probability of events,triggered conditional statements, or triggered patterns based onobserved scores. In some embodiments, the parameters of the neuralnetwork may be transferred to other neural networks for furthertraining. For example, a first neural network may be trained using theoutcome scores as inputs and sets of events as outputs, and the weightsand biases of the training may be transmitted to a second neural networkfor further training. The second neural network may then be used toindicate whether a particular event had a sufficiently high possibilityof occurring based on a score or score change. In addition, themulti-iteration score may include outputs of a convolutional neuralnetwork, which may be used to determine behavior patterns acrossmultiple smart contracts.

In some embodiments, the symbolic AI system may use a fuzzy logic methodto predict the occurrence of an event based on the outcomes of a smartcontract. A fuzzy logic method may include fuzzifying inputs by usingone or more membership functions to determine a set of scalar values foreach of a set of inputs, where the set of scalar values indicate thedegree of membership of the inputs of a set of labels for each of theinputs of a smart contract being simulated by a symbolic AI system. Forexample, the system may use a membership function to determine apercentage values between 0% and 100% for a set of labels such as“profitable,” “risky,” or the like. The percentage values may indicate,for each of the smart contracts, a degree of membership to each of thelabels. The symbolic AI system may then determine an fuzzified outcomescore based on the set of fuzzified data by first using a set of rulesin combination with an inference engine to determines the degree ofmatch associated with the fuzzy input and determine which of the set ofrules to implement. As used herein, an inference engine may be a systemthat applies a set of pre-defined rules. For example, an inferenceengine may include a set of “if-then” expressions that providedresponses to particular inputs. By using the inference engine incombination with the set of rules, the fuzzified outcome score mayprovide an indication of a broader label for the smart contract, such as“unconventional,” “risk too high,” or the like. In some embodiments, thesymbolic AI system may defuzzify the fuzzified outcome score usingvarious methods such as centroid of area method, bisector of areamethod, mean of maximum method, or the like. The defuzzifying processmay result in a defuzzified outcome score that may also be used todetermine a label.

In some embodiments, each of the scenarios may have an associatedscenario weight, where the associated scenario may be a numeric valuerepresenting a normalized or nonnormalized probability of occurrence.For example, a smart contract may be processed based one of threepossible scenarios, where the first scenario may have a weighting valueequal to 0.5, the second scenario may have a weighting value equal to0.35, and the third scenario may have a weighting value equal to 0.15.The system may use the associated scenario weights when determining amulti-iteration score. For example, if the first, second, and thirdscenarios results in allocating, respectively, 100, −10, or −100computing resource units to a first entity, the system may determinethat the expectation resource units allocated to the first entity isequal to 31.5 computing resource units and use the expectation resourceunits as the allocation value. While the above described using a scalarvalue as a weighting value, some embodiments may instead use aprobability distribution as an associated scenario weight for each ofthe scenarios and determine the weighting value.

In some embodiments, the system may determine if data from an additionalsmart contract is to be processed, as indicated by block 350. Asdiscussed in this disclosure, the process 300 may execute a number ofsimulations of different smart contracts to simulate possible outcomesand score changes. In some embodiments, each of the set of selectedsmart contracts may be simulated using a symbolic AI simulator.Furthermore, each of the set smart contracts may use the same set ofweights/probability values to determine unique scenarios. For example,using the same set of weights corresponding to different combinations ofavailable vertices, the system may determine a first scenario for afirst symbolic AI model and a second scenario for a second symbolic AImodel, where the first and second symbolic AI models have directedgraphs that are different from each other. In some embodiments, the sameweights may be used because the plurality of symbolic AI models mayinclude vertices based on the same set of statuses and same set oflogical categories. If the additional iterations are needed, operationsof the process 300 may return to block 308. Otherwise, operations of theprocess 300 may proceed to block 354.

In some embodiments, the process 300 includes determining amulti-protocol score based on the outcome scores across multiple smartcontracts, as indicated by block 354. A multi-protocol score may be anyscore that is determined based on a plurality of outcomes fromsimulating different smart contracts, where the plurality of outcomesmay include either or both multi-iteration scores or scores determinedafter a single iteration. In some embodiments, the multi-protocol scoremay be determined by determining a population of scores associated witha given entity. For example, a population of scores may be a populationof expected income across a population of 500 instantiated smartcontracts. The multi-protocol score may be a total income value, averageincome value, kurtosis income value, or the like.

In some embodiments, one or more methods to determine a multi-iterationscore may be used to determine a multi-protocol score. For example, useof fuzzy logic, Bayesian inference, or neural networks may be used topredict multi-protocol scores. For example, some embodiments may use afirst set of multi-iteration scores from a plurality of smart contractsimulations as inputs and a second set of multi-iteration scores fromthe same plurality of smart contract simulations as outputs whentraining a neural network, where a set of multi-protocol score may beone or more the parameters of the trained neural network. For example,some embodiments may include a neural network trained to predict theprobability that a specific type of smart contract was used based onmulti-iteration scores such as an average payment duration and anaverage payment amount.

In some embodiments, multiple multi-protocol scores may be used todetermine risk between a first entity and a second entity. For example,operations of the process 300 may be performed to determine a list ofsmart contracts shared by a first entity and a second entity and predictpossible risks to the first entity in scenarios resulting from theincapability of the second entity to fulfill one or more norms in thelist of smart contracts. In some embodiments, the risk posed to a firstentity by a second entity may include considerations for intermediaterelationships. For example, a first entity may be owed multiple amountsfrom a plurality of entities other than a second entity, and a secondentity may owe multiple amounts to the plurality of entities. In someembodiments, a risk associated with the total amount of a score value tobe collected by the first entity from the plurality of entities may beassessed based on the risk of the second entity failing to fulfill oneor more obligations to transfer score values to one or more of theplurality of entities. While the relationship between the first entityand the second entity may be difficult to determine using conventionalsmart contract systems if no explicit privity relations are listed inthe smart contracts, the symbolic AI models described in this disclosureallow these relationships to be determined by searching through entitylists or crawling through one or more privity graphs.

FIGS. 4-9 below show a set of directed graphs that represent examples ofprogram state of a smart contract or a simulation of a smart contract.Each vertex of the directed graph may represent conditional statementsthat encode or are otherwise associated with norm conditions and outcomesubroutines that may be executed when a norm condition is satisfied.Each directed graph edge of the directed graph may represent arelationship between different conditional statements. For example, thetail vertex of a directed graph edge may represent a norm vertex that,if triggered, will activate the respective head vertex of the directedgraph edge. As used in this disclosure, the direction of a directedgraph edge points from the tail vertex of the directed graph edge to thehead vertex of the directed graph edge. Furthermore, the direction ofthe of the directed graph edge may indicate that the respective headvertex to which the directed graph edge points is made triggerable basedon a triggering of the respective tail vertex. In some embodiments, anorm vertex may be triggered if the trigger direction is the same as thedirected graph edge direction for each directed graph edge. In someembodiments, the direction of a directed graph edge associated with normcondition may be used to categorize a norm or norm vertex.

FIG. 4 show a computer system for operating one or more symbolic AImodels, in accordance with some embodiments of the present techniques.As shown in FIG. 4, a system 400 may include computer system 402, firstentity system 404, second entity system 406 or other components. Thecomputer system 402 may include a processor 412 and a local memory 416,or other components. Each of the first entity system 404 or secondentity system 406 may include any type of mobile computing device, fixedcomputing device, or other electronic device. In some embodiments, thefirst entity system 404 may perform transactions with the second entitysystem 406 by sending messages via the network 450 to the computersystem 402. In some embodiments, the computer system 402 may execute oneor more applications using one or more symbolic AI models with aprocessor 412. In addition, the computer system 402 may be used toperform one or more of the operations described in this disclosure forthe process 100 or the process 300. Parameters, variables, and othervalues used by a symbolic AI model or provided by the symbolic AI modelmay be retrieved or stored in the local memory 416. In some embodiments,parameters, variables, or other values used or provided by the computersystem 402, entity systems 404-406, or other systems may be sent to orretrieved from the remote data storage 444 via the network 450.

FIG. 5 includes a set of directed graphs representing triggered normsand their consequent norms, in accordance with some embodiments of thepresent techniques. The table 500 shows various triggered vertices andtheir respective consequent vertices in the form of directed graphs. Insome embodiments, the system may include categories for norms of a smartcontract based on a deontic logic model, where the categories mayinclude obligation norms, rights norms, or prohibition norms. Inaddition to various contract-specific ramifications of these categories,norms within each category may share a common set of traits with respectto their transiency and possible outcomes. As shown in table 500, therelationship between a triggered norm and its consequent norms may berepresented as a directed graph, where each of the norms may berepresented by a vertex of the directed graph and where each triggeringevent may be used to as a label associated with a graph edge.

Box 510 includes a directed graph representing a smart contract state(or simulation of the smart contract state) after an event satisfying anorm condition of the obligation norm represented by the norm vertex511. As shown in box 510, after a determination that the norm conditionP associated with the norm vertex 511 is satisfied by an event(indicated by the directed graph edge 512), the system may generate anadjacent vertex 513 indicating that the norm vertex 511 is satisfied,where a norm status of the adjacent vertex 513 may be set as “terminal”to indicate that the adjacent vertex is terminal. In some embodiments, adetermination that the state of the smart contract or simulation thereofis terminal may be made if a vertex of the smart contract or simulationthereof indicated to be terminal. In some embodiments, instead ofgenerating the adjacent vertex 513, the system may update a norm statusassociated with the norm vertex 511 to indicate that the norm vertex 511is satisfied. For example, the system may update a norm vertexassociated with the obligation norm by setting a norm status associatedwith the norm vertex to “satisfied,” “terminal,” or some other indicatorthat the obligation norm has been satisfied by an event. In someembodiments, updating a norm vertex associated with the obligation normmay be represented by the statement 6, where

$\overset{\mspace{14mu} P\mspace{14mu}}{\rightarrow}$

represents a result of the norm condition associated with the obligationnorm “OP” being satisfied, and S represents the generation of a normvertex indicating that the conditions of the obligation norm have beensatisfied:

$\begin{matrix}{{\ln \mspace{11mu} {OP}}\overset{\mspace{11mu} P\mspace{11mu}}{\rightarrow}S} & (6)\end{matrix}$

As shown in box 520, an norm condition P may end up not satisfying anorm condition associated with the norm vertex 521 after satisfying acondition expiration threshold, where the norm vertex 521 is associatedwith an obligation norm. In response, the system may update the normvertex 521 by setting a norm status associated with the norm vertex 521to “failed” or some other indicator that the norm condition associatedwith the norm vertex 521 has been not satisfied. For example, an eventmay indicate that a condition expiration threshold has been satisfiedwithout an obligation norm condition being satisfied. In response, thesystem may generate or otherwise set as triggerable the set ofconsequent norms associated with adjacent vertices 523, where therelationship between a failure to satisfy a norm condition P of the normvertex 521 and the adjacent vertices 523 is indicated by the directedgraph edges 522. In some embodiments, the generation of the adjacentvertices may be represented by the statement 7, where

$\overset{\mspace{11mu} {\; P}\mspace{14mu}}{\rightarrow}$

indicates that the instructions to the right of the symbol

$\overset{\mspace{11mu} {\; P}\mspace{14mu}}{\rightarrow}$

are to be performed if a norm condition “OP” is not satisfied, and theinstructions represented by the symbolic combination Λ_(i)X_(i)Q_(i)represents the generation or activation of the consequent norms thatresult from the failure of OP:

$\begin{matrix}{{OP}\overset{\mspace{11mu} {\; P}\mspace{14mu}}{\rightarrow}{\Lambda_{i}X_{i}Q_{i}}} & (7)\end{matrix}$

In some embodiments, in response to an event satisfying a norm conditionof a rights norm, the system may update a norm vertex associated withthe rights norm by setting a norm status associated with the norm vertexto “exercised” or some other indicator that the rights norm has beentriggered based on an event. For example, as shown in box 530, inresponse to an event satisfying a norm condition associated a rightsnorm represented by the norm vertex 531, the system may update a normvertex associated with the norm vertex 531 by setting a norm statusassociated with the norm vertex 531 to “exercised” or some otherindicator that the rights norm has been exercised. In response, thesystem may generate or otherwise set as triggerable the set ofconsequent norms associated with adjacent vertices 533, where therelationship between satisfying a norm condition P associated with thenorm vertex 531 and the set of consequent norms associated with adjacentvertices 533 is indicated by the directed graph edges 532. Furthermore,in some embodiments, a rights norm may be contrasted with an obligationnorm by allowing a rights norm to remain triggerable after triggering.This may be implemented by further generating or otherwise setting astriggerable the rights norm associated with the rights norm vertex 534.In some embodiments, a rights norm may expire after use. For example,some embodiments may not generate the rights norm vertex 534 aftertriggering the norm vertex 531. In some embodiments, the operationdescribed above may be represented by statement 8 below, where theresult of triggering a rights norm RP₁ by satisfying the norm conditionP may result in a conjunction of newly-triggerable consequent normsΛ_(i)X_(i)Q_(i) and a rights norm RP₂ that is identical to the rightsnorm RP₁, where Λ represents a mathematical conjunctive operation:

$\begin{matrix}{{RP_{1}}\overset{\mspace{14mu} P\mspace{11mu}}{\rightarrow}{\Lambda_{i}X_{i}Q_{i}\Lambda RP_{2}}} & (8)\end{matrix}$

In some embodiments, in response to an event satisfying the normcondition of a “prohibition” norm, the system may update a norm vertexassociated with the “prohibition” norm by setting a norm statusassociated with the norm vertex to “violated” or some other indicatorthat the “prohibitions” norm has been triggered based on an event. Forexample, as shown in box 550, an event may satisfy a norm condition Passociated with the prohibition norm represented by a norm vertex 551.In response, the system may update the norm vertex 551 by setting a normstatus associated with the norm vertex 551 to “violated” or some otherindicator that the associated prohibitions norm condition has beensatisfied. In response, the system may generate or otherwise set astriggerable the set of consequent norms associated with adjacentvertices 553, where the relationship between satisfying a norm conditionP associated with the norm vertex 551 and the set of consequent normsassociated with adjacent vertices 553 is indicated by the directed graphedges 552. Furthermore, in some embodiments, a prohibitions norm may becontrasted with an obligation norm by allowing a prohibitions norm tosurvive triggering. In addition, in some embodiments, triggering aprohibitions norm may result in the system decreasing a valuerepresenting the state of the smart contract. This may be implemented byfurther generating or otherwise setting as triggerable the prohibitionsnorm associated with the prohibitions norm vertex 554 after triggeringthe norm vertex 551. In some embodiments, the operation described abovemay be represented by statement 9 below, where the result of triggeringa prohibition norm PP₁ by satisfying the norm condition P may result ina conjunction of newly-triggerable consequent norms Λ_(i)X_(i)Q_(i) anda prohibition norm PP₂ that is identical to the prohibition norm PP₁,where Λ represents a mathematical conjunctive operation:

$\begin{matrix}{{PP_{1}}\overset{\mspace{14mu} P\mspace{14mu}}{\rightarrow}{\Lambda_{i}X_{i}Q_{i}\Lambda PP_{2}}} & (9)\end{matrix}$

FIG. 6 includes a set of directed graphs representing possiblecancelling relationships and possible permissive relationships betweennorms, in accordance with some embodiments of the present techniques.The table 600 includes a left column that includes a directed graph 610representing an initial state and a directed graph 620 that represents afirst possible outcome state of the initial state and a directed graph630 that represents a second possible outcome state of the initialstate. In some embodiments, a norm condition may be a cancellationcondition, where satisfying a cancellation condition results in thecancellation of one or more norms. Cancelling a norm may includedeactivating a norm, deleting the norm, deleting graph edges to thenorm, or otherwise or otherwise setting the norm as not triggerable. Forexample, an obligations norm may include a cancellation outcomesubroutine, where triggering the obligations norm may result in thecancellation of one or more norms adjacent to the obligations norm. Insome embodiments, the effect of satisfying a cancellation norm may berepresented by statement 10 below, where XP may represent an obligationsnorm,

$\overset{\mspace{11mu} {P.{P}}\mspace{11mu}}{\rightarrow}$

may indicate that the event which triggers the norm XP occurs when thenorm condition P is either satisfied or failed, Λ_(i)X_(i)Q_(i)represents the set of consequent norms that are set to be triggerablebased on the event triggering XP, and X_(j)U_(j) may represent the setof consequent norms that cancelled based on event triggering XP:

$\begin{matrix}{{XP}\overset{\mspace{11mu} {P.{P}}\mspace{14mu}}{\rightarrow}{\Lambda_{i}X_{i}Q_{i}\Lambda \Lambda_{j}{{X_{j}U_{j}}}}} & (10)\end{matrix}$

As shown by statement 10 above, one or more norms may be cancelled. Insome embodiments, a cancellation may be implemented as an inactive graphedge between the norm XP and the norms X_(j)U_(j), where the graph edgerepresenting the conditional relationship between the norm XP and thenorms X_(j)U_(j) are directed towards the norm XP. In some embodiments,the cancellation of a norm may be implemented by setting an indicator toindicate that a norm or condition associated with the cancelled norm isno longer triggerable.

The directed graph 610 may represent a state of a start contract and mayinclude the first vertex 611, second vertex 613, third vertex 617, andfourth vertex 619, each of which are associated with a norm of a smartcontract. The directed graph 610 also depicts a mutual cancellationrelationship between the norm associated with the second vertex 613 andthe third vertex 617 represented by the XQ1-XQ2 graph edge 614, where amutual cancellation relationship of a pair of norm vertices may includea cancellation of one norm vertex of the pair upon triggering of theother norm vertex of the pair. The directed graph 610 also depicts aunidirectional cancellation relationship between the norm associatedwith the fourth vertex 619 and the third vertex 617 as represented bythe XP2-XQ2 graph edge 618. In some embodiments, satisfying or otherwisetriggering the norm associated with the third vertex 617 may instantiatethe RZ-XQ2 graph edge 618 and cancel the fourth vertex 619. In someembodiments, each of vertices and graph edges shown in FIG. 5 may berepresented using a protocol simulation program. For example, the firstvertex 611 may be modeled in a simulation program and may be associatedwith a conditional statement of a smart contract.

In some embodiments, the state represented by the directed graph 610 mayadvance to the state represented by the directed graph 620. The staterepresented by the directed graph 620 may be achieved by triggering thenorm associated with the second vertex 613, which may result in thecancellation of the norm associated with the third vertex 617.Furthermore, as illustrated by the directed graph 620, triggering thenorm associated with the second vertex 613 may also result in theactivation of fifth vertex 621 and sixth vertex 623. In addition,triggering the norm associated with the third vertex 617 may result inthe cancellation of the norm associated with the fourth vertex 619.Furthermore, as illustrated by the directed graph 630, triggering thenorm associated with the third vertex 617 may also result in theactivation of a seventh vertex 631 and eighth vertex 633. Each of thesetriggering behaviors may be implemented directly by a smart contract.

In some embodiments, the triggering relationship described in thisdisclosure may be modeled using a symbolic AI system that may keep trackof any scores associated with events that trigger the norms and theoutcomes of triggering the norms. For example, a first probability valuemay be assigned to the state represented by the directed graph 620 and asecond probability value may be assigned to the state represented by thedirected graph 630 during a simulation of the smart contract. Thesymbolic AI system may use the first and second probability values toadvance the state represented by either the directed graph 620 or thedirected graph 630 over multiple iterations to compute a multi-iterationscore using the methods described in this disclosure. For example, ifthe first probability value is 20% and the second probability value is80%, and a first score represented by the directed graph 620 is equal to100 cryptocurrency units and a second score represented by the directedgraph 630 is equal to 1000 cryptocurrency units, a multi-iteration scoremay be equal to 820 cryptocurrency units.

The right column of table 600 includes a directed graph 650, which mayrepresent an initial state of a smart contract (or simulation thereof).The right column of table 600 also includes a directed graph 660 thatrepresents a first possible outcome state of the initial state and adirected graph 670 that represents a subsequent possible outcome stateof the first possible outcome state. The initial state represented bythe directed graph 650 may include a permissive condition of apermission norm, where satisfying a permissive condition may result inthe activation of one or more norms. For example, after being activated,a rights norm RP may include a set of permissions {RV_(k)} that aretriggered after satisfying an norm condition associated with the rightsnorm RP, where the rights norm RP may also be described as a permissionnorm. Triggering the set of permissions {RV_(k)} may either set the normXP to be triggerable or otherwise prevent an outcome subroutine of thenorm XP from being executed until the set of permissions {RV_(k)} aretriggered. This relationship may be represented by statement 11 below,where XP may represent an obligations norm, RV_(k) represents thepermissions that must be triggered before XP may be triggered,

$\overset{\mspace{11mu} {P.{P}}\mspace{11mu}}{\rightarrow}$

may indicate that the event which triggers the norm XP occurs when thenorm condition P is either satisfied or failed, Λ_(i)X_(i)Q_(i)represents the set of consequent norms that are set to be triggerablebased on the event triggering XP after the permissions RV_(k) aretriggered, and X_(j)U_(j) may represent the set of consequent norms thatcancelled based on event triggering XP after the permissions RV_(k) aretriggered:

$\begin{matrix}\left. {XP} \middle| {{RV}_{k}\overset{\mspace{11mu} {P.{P}}\mspace{14mu}}{\rightarrow}{\Lambda_{i}X_{i}Q_{i}\Lambda \Lambda_{j}{{X_{j}U_{j}}}}} \right. & (11)\end{matrix}$

As shown by statement 11 above, XP may be set to be triggerable upontriggering of the permission RV_(k). Triggering XP after the permissionsRV_(k) are triggered results in activation of the consequent normsΛ_(i)X_(i)Q_(i) and cancels the norms X_(j)U_(j). In some embodiments,the conditions needed to trigger permissions may be activated inconjunction with rights norms dependent on the permissions, and thus XPand RV_(k) may be activated as a result of triggering the same triggerednorm. In some embodiments, permission behavior may be performed by asmart contract or a simulation thereof by modifying a first status of afirst vertex and a second status of a second vertex to indicate that thefirst and second vertices are triggered, where the first vertex mayrepresent a first rights norm such as XP and the second vertex mayrepresent a permission norm such as a norm having outcome permissionsRV_(k). The smart contract, or a simulation thereof, may trigger a thirdvertex that is adjacent to the first vertex and the second vertex suchas a vertex in Λ_(i)X_(i)Q_(i) in response to the first and secondstatuses now being triggered.

The directed graph 650 may include a first vertex 651, second vertex653, third vertex 657, and fourth vertex 659. The directed graph 650also depicts a mutual cancellation relationship between the normassociated with the second vertex 653 and the third vertex 657represented by the XQ1-XQ2 graph edge 654. The directed graph 650 alsodepicts a permission relationship between the norm associated with thefourth vertex 659 and the third vertex 657 as represented by the RZ-XQ2graph edge 658, where the fourth vertex 659 may include or otherwise beassociated with permission conditions that must be satisfied in order totrigger the third vertex 657. In some embodiments, satisfying orotherwise triggering the norm associated with the fourth vertex 659 mayinstantiate the RZ-XQ2 graph edge 658 and allow the outcome subroutinesof the third vertex 657 to be executed.

In some embodiments, the program state represented by the directed graph650 may produce an outcome state represented by the directed graph 660.The outcome state represented by the directed graph 660 may be achievedby satisfying a norm condition associated with the fourth vertex 659. Insome embodiments, after the XQ1-XQ2 graph edge 654 becomes instantiated,an event satisfying a norm condition associated with the third vertex657 may result in the program state represented by the directed graph670. The directed graph 670 may represent a program state where the normassociated with the third vertex 657 is triggered, resulting in theactivation of additional norms associated with the fifth vertex 671 andsixth vertex 673.

In some embodiments, a symbolic AI system may be used to generate ascenario that includes a sequence of inputs having a first input and asecond input. The first input may advance the state represented by thedirected graph 650 to the state represented by the directed graph 660and the second input may advance the state represented by the directedgraph 660 to the state represented by the directed graph 670. Thesequence of inputs may be determined using any of the methods describedin this disclosure. For example, the sequence of inputs may bedetermined using a Monte Carlo method, a neural network, or the like.

FIG. 7 includes a set of directed graphs representing a set of possibleoutcome states based on events corresponding to the satisfaction orfailure of a set of obligations norms, in accordance with someembodiments of the present techniques. The set of directed graphs 710includes a set of three vertices 711-713, each representing anobligation norm to perform a set of related tasks. In some embodiments,the obligation norm may represent an obligation to transmit digitalassets, deliver a data payload, or perform a computation. For example,the obligation norm represented by the first vertex 711 may beassociated with an obligation for a first entity to transmit a downpayment to a second entity, where a determination that the down paymentoccurred may be based on an event message sent by the second entityconfirming that payment was delivered. The obligation norm representedby the second vertex 712 may be associated with an obligation for thesecond entity to deliver an asset to the first entity, where adetermination that the asset was delivered may be based on an eventmessage sent by the second entity confirming that the asset wasdelivered. The obligation norm represented by the third vertex 713 maybe associated with an obligation for the first entity to pay a balancevalue to the second entity.

The set of directed graphs 720 may represent a first outcome state thatmay result from the program state represented by the set of directedgraphs 710, where each of the obligation norms represented by the threevertices 711-713 are satisfied. In some embodiments, a smart contractsimulation system such as a symbolic AI system may assign a probabilityvalue to the possibility the state represented by the set of directedgraphs 710 is advanced to the outcome state represented by the set ofdirected graphs 720. For example, a symbolic AI system may assign aprobability for the outcome state represented by the set of directedgraphs 720 to be equal to 82% when starting from the state representedby the set of directed graphs 710. The symbolic AI system may thenperform a set of simulations based on this probability value using aMonte Carlo simulator.

The set of directed graphs 730 may represent a second outcome state thatmay result from the program state represented by the set of directedgraphs 710, where the first obligation is not satisfied and the time hasexceeded a condition expiration threshold associated with the firstvertex 711. As shown in the set of directed graphs 730, a failure tomeet the first obligation represented by the first vertex 711 may resultin a system generating or otherwise activating norms associated with afourth vertex 721 and a fifth vertex 722. In some embodiments, the normassociated with the fourth vertex 721 may represent a first entity'sright to cure the payment failure and the norm associated with the fifthvertex 722 may represent a second entity's right to terminate the smartcontract. The bidirectional graph edge 723 indicates that triggering oneof the pair of vertices 721-722 will cancel or otherwise render asinactive the other of the pair of vertices 721, which may indicate thatcuring a failed obligation and terminating the smart contract may bemutually exclusive outcomes. In some embodiments, a symbolic AI system(or other modeling system) may assign a probability value to thepossibility the state represented by the set of directed graphs 710 isadvanced to the outcome state represented by the set of directed graphs720. For example, the symbolic AI system may assign a probability forthe outcome state represented by the set of directed graphs 720 to beequal to 6% when performing a simulation based on the smart contractprogram state represented by the set of directed graphs 710.

In some embodiments, the state represented by the set of directed graphs730 may be advanced to the state represented by a set of directed graphs740. In some embodiments, the state represented by a set of directedgraphs 740 may be an outcome state after the norm associated with thefourth vertex 721 is triggered. As shown in the set of directed graphs740, triggering the norm associated with the fourth vertex 721 mayresult in cancelling the norm associated with fifth vertex 722. In someembodiments, a symbolic AI system may use probability value representingthe probability of the state represented by the set of directed graphs730 advancing to the state represented by a set of directed graphs 740.For example, a symbolic AI system may use 50% as the probability thatthe state represented by the set of directed graphs 730 advances to thestate represented by a set of directed graphs 740. If the probability ofthe state represented by the set of directed graphs 720 advancing to thestate represented by a set of directed graphs 730 is equal to 6%, thiswould mean that the probability of the state represented by the set ofdirected graphs 710 advancing to the state represented by a set ofdirected graphs 740 is equal to 3% by applying the multiplication rulefor the probability of independent events.

In some embodiments, the state represented by the set of directed graphs730 may be advanced to the state represented by a set of directed graphs750. In some embodiments, the state represented by a set of directedgraphs 750 may be an outcome state after the norm associated with thefifth vertex 722 is triggered. As shown in the set of directed graphs750, triggering the norm associated with the fifth vertex 722 may resultin cancelling the norm associated with second vertex 712, third vertex713, and fourth vertex 721. In some embodiments, a symbolic AI systemmay assign a probability value to the possibility of a smart contractstate being in the outcome state represented by the set of directedgraphs 750 when starting from the program state represented by the setof directed graphs 730. In some embodiments, the probability valuesassociated with each state may be updated after each iteration in a setof simulated iterations using one or more of the methods in thisdisclosure. For example, some embodiments may apply a MCTS method toexplore the program states represented by the sets of directed graphs710, 720, 730, and 740 across multiple iterations while keeping track ofscores for each iteration in order to determine outcome scores for eachiteration and multi-iteration scores.

FIG. 8 includes a set of directed graphs representing a set of possibleoutcome states after a condition of a second obligations norm of a setof obligations norms is not satisfied, in accordance with someembodiments of the present techniques. In some embodiments, the set ofdirected graphs 810 may represent an initial state of a smart contract.Alternatively, the set of directed graphs 810 may represent an outcomestate. For example, the program state represented by the set of directedgraphs 810 may be an outcome state of the program state represented bythe set of directed graphs 710, with an associated occurrenceprobability equal to 6%. The set of directed graphs 810 may represent afailure to satisfy a norm condition associated with the second vertex812. In some embodiments, the second vertex 812 may represent anobligation norm indicating an obligation for a second entity to deliveran asset, such as a schematic, to the first entity.

In some embodiments, the state represented by the set of directed graphs810 may be advanced to the state represented by a set of directed graphs820. In some embodiments, the state represented by a set of directedgraphs 820 may be an outcome state after the norm associated with thefifth vertex 822 is triggered. As shown in the set of directed graphs820, triggering the norm associated with the fifth vertex 822 may resultin cancelling the norm associated with sixth vertex 823. In someembodiments, the fifth vertex 822 may represent a first entity's rightto terminate the order and obtain a refund. This outcome may berepresented by the eighth vertex 831, which may represent an obligationnorm indicating that the second entity has an obligation to pay thefirst entity, and that this obligation may either be satisfied orfailed, as indicated by vertices 841 and 842, respectively.

In some embodiments, the state represented by the set of directed graphs810 may be advanced to the state represented by a set of directed graphs830. In some embodiments, the state represented by a set of directedgraphs 820 may be an outcome state after the norm associated with thesixth vertex 823 is triggered. As shown in the set of directed graphs830, triggering the norm associated with the sixth vertex 823 may resultin cancelling the norm associated with sixth vertex 823. In someembodiments, the sixth vertex 823 may represent a first entity's rightto cure the failure to satisfy the norm represented by the second vertex812. This outcome may be represented by the ninth vertex 832, which mayrepresent an obligation norm indicating that the second entity has anobligation to deliver an asset to the first entity, and that thisobligation may either be satisfied or failed, as indicated by vertices843 and 844, respectively.

In some embodiments, a symbolic AI system may assign a probability valueto the possibility of a smart contract state being in the outcome staterepresented by the set of directed graphs 820 or set of directed graphs830 when starting from the program state represented by the set ofdirected graphs 810. For example, a symbolic AI system may determinethat the probability that the outcome state represented by the set ofdirected graphs 820 is equal to 40%. Similarly, the symbolic AI systemmay determine that the probability that the outcome state represented bythe set of directed graphs 830 is equal to 60%. In some embodiments, thesymbolic AI system may use a Bayesian inference to determine if anobligation norm was failed was failed based on a probabilitydistribution computed from the scores associated with program statessuch as those states represented by the sets of directed graphs 820 or830. For example, the symbolic AI system may acquire a new score valueand, based on the score value, predict whether an obligation representedby the second vertex 812 was failed.

FIG. 9 includes a set of directed graphs representing a set of possibleoutcome states after a condition of a third obligations norm of a set ofobligations norms is not satisfied, in accordance with some embodimentsof the present techniques. In some embodiments, the set of directedgraphs 910 may represent an initial state of a smart contract.Alternatively, the set of directed graphs 910 may represent an outcomestate. For example, the program state represented by the set of directedgraphs 910 may be an outcome state of the program state represented bythe set of directed graphs 810, with an associated occurrenceprobability equal to 6%. The set of directed graphs 910 may represent afailure to satisfy a norm condition associated with the third vertex913. In some embodiments, the third vertex 913 may represent anobligation norm indicating an obligation for a first entity to pay abalance value to the second entity. Triggering the norm associated withthird vertex 913 by failing to satisfy an associated obligationcondition may result in activating norms associated with a sixth vertex923 and a seventh vertex 924. In some embodiments, the norm associatedwith the sixth vertex 923 may represent a first entity's right to curethe payment failure and the norm associated with the seventh vertex 924may represent a second entity's right to declare a breach and flag thefirst entity for further action (e.g. initiate arbitration, incur areputation score decrease, or the like).

In some embodiments, the state represented by the set of directed graphs910 may be advanced to the state represented by a set of directed graphs920. In some embodiments, the state represented by a set of directedgraphs 920 may be an outcome state after the norm associated with thesixth vertex 923 is triggered. In some embodiments, the norm associatedwith the sixth vertex 923 may represent a first entity's right to curethe payment failure, and thus triggering the rights norm associated withthe sixth vertex 923 may represent a first entity's right to cure thefailure. As indicated by the satisfaction vertex 931, curing the paymentfailure may end all outstanding obligations of the smart contract.

In some embodiments, the state represented by the set of directed graphs910 may be advanced to the state represented by a set of directed graphs930. In some embodiments, the state represented by a set of directedgraphs 930 may be an outcome state after the norm associated with theseventh vertex 924 is triggered. In some embodiments, the normassociated with the seventh vertex 924 may represent a second entity'sright to declare a breach, and thus triggering the rights normassociated with the seventh vertex 924 may represent a second entity'sdeclaration of contract breach. This may result in the activation of thefailure vertex 932, which may include outcome subroutines that sends amessage indicating that the smart contract is in breach to a third partyor sends instructions to an API of another application.

FIG. 10 includes a set of directed graphs representing a pair ofpossible outcome states after a condition of a fourth obligations normof a set of obligations norms is not satisfied, in accordance with someembodiments of the present techniques. FIG. 10 includes a directed graph1010 representing a first program state of a smart contract or asymbolic AI simulation thereof. The program state represented by thedirected graph 1010 may be changed to the program state represented by adirected graph 1020. Alternatively, the program state represented by thedirected graph 1010 may be changed to the program state represented by adirected graph 1030. The directed graph 1010 includes a first vertex1011 that may represent an obligations norm. In some embodiments, thefirst vertex 1011 may represent an obligation norm reflecting anobligation to pay by the time a condition expiration threshold issatisfied. If the obligation to pay is failed, the obligation normassociated with the first vertex 1011 may be triggered and the rightsnorms associated with the second vertex 1012 and the third vertex 1013may be activated. The second vertex 1012 may represent a rights norm tocure the failure to satisfy the obligations norm represented by thefirst vertex 1011, and the third vertex 1013 may represent a rights normto accelerate the payments the smart contract. The directed graph 1010also includes a pair of vertices 1014-1015 representing futureobligations to pay, where exercising the rights norm represented by thethird vertex 1013 may cancel the future obligations to pay.

In some embodiments, the state represented by the directed graph 1010may be advanced to the state represented by the directed graph 1020. Insome embodiments, the state represented by the directed graph 1020 maybe an outcome state after the norm associated with the second vertex1012 is triggered. In some embodiments, the norm associated with thesecond vertex 1012 may represent a right to cure the failure to satisfythe norm condition associated with the first vertex 1011. As indicatedby the directed graph 1020, exercising the rights norm associated withthe second vertex 1012 may satisfy the norm and activate the vertex1023, which may indicate that the rights norm associated with the secondvertex 1012 has been satisfied.

In some embodiments, the state represented by the directed graph 1010may be advanced to the state represented by the directed graph 1030. Insome embodiments, the state represented by the directed graph 1030 maybe an outcome state after the norm associated with the third vertex 1013is triggered. In some embodiments, the rights norm associated with thethird vertex 1013 may represent a right to accelerate payment.Triggering the rights norm associated with the third vertex 1013 maycancel the rights norm associated with the second vertex 1012. Inaddition, triggering the rights norm associated with the third vertex1013 may also cancel the obligation norms associated with the vertices1014-1015. Triggering the rights norm associated with the third vertex1013 may cause the system to activate a new obligation norm associatedwith the fourth vertex 1031. In some embodiments, the new obligationnorm may include norm conditions to determine whether a first entitytransmits a payment amount to the second entity. For example, the newobligation norm may determine whether the first entity transmitted theentirety of a principal payment of a loan to the second entity. Theobligation norm associated with the fourth vertex 1031 may be associatedto a satisfaction norm represented by a fifth vertex 1041 or a failurenorm represented by a sixth vertex 1042.

In some embodiments, advancement of the state represented by thedirected graph 1010 to the state represented by the directed graph 1020or the state represented by the directed graph 1030 may be simulatedusing a symbolic AI system. For example, the state represented by thedirected graph 1010 may be copied into a symbolic AI model, where boththe conditional statements associated with the nodes and of the directedgraph the edges connecting the nodes of the directed graph may becopied. A symbolic AI system may then simulate state changes using thesymbolic AI model to determine an expected value for a smart contractthat has already reached the state represented by the directed graph1010, where the expected value may be a multi-iteration score.

In some embodiments, each of the smart contracts represented by thedirected graphs 610, 650, 710, and 1010 may be analyzed using a symbolicAI system to determine one or more multi-protocol scores. For example,each of the smart contracts represented by the directed graphs 610, 650,710, and 1010 may be analyzed to produce multi-iteration scores such asaverage scores for each smart contract and a kurtosis value of expectedscores. In some embodiments, the analysis may use the same rules togovern the behavior entities in the smart contract by basing the ruleson logic types and vertex statuses instead of the contexts of specificagreements. For example, each smart contract simulation may be simulatedwith a set of rules that include a rule that the probability that arights norm to cure is triggered instead of a rights norm to acceleratebeing triggered is equal to 90%. The multi-iteration scores may then befurther analyzed to determine a multi-protocol score. For example, basedon a multi-iteration score representing a risk score associated witheach of the smart contracts, the total exposed risk of a first entitywith respect to a second entity may be determined, where the totalexposed risk may be a multi-protocol score.

FIG. 11 is a block diagram illustrating an example of a tamper-evidentdata store that may be used to render program state tamper-evident andperform the operations in this disclosure, in accordance with someembodiments of the present techniques. In some embodiments, thetamper-evident data store may be a distributed ledger, such as ablockchain (or other distributed ledger) of one of the blockchain-basedcomputing platforms described in this disclosure. FIG. 11 depict twoblocks in a blockchain, and also depicts tries of cryptographic hashpointers having root hashes stored in the two blocks. The illustratedarrows may represent pointers (e.g., cryptographic hash). For example,the arrow 1103 may represent a pointer from a later block to block 1104that joints the two blocks together. In some embodiments, blocks may beconsecutive. Alternatively, the data from the use of a smart contractmay skip several blocks between uses of the smart contract. As shown inFIG. 11, a tamper-evident data store 1102 may include a linked list ofblocks that includes the block 1104 and other blocks, where the linkedlist of blocks may be connected by cryptographic hash pointers.

In some embodiments, a directed acyclic graph of cryptographic hashpointers may be used to represent the tamper-evident data store 1102.Some or all of the nodes of the directed acyclic graph may be used toform a skip list or linked list, such as the node corresponding to orotherwise representing as block 1104. In some embodiments, each blockrepresented by a node of this list may include multiple values ascontent. For example, each respective block may include a timestamp ofcreation 1106, a cryptographic hash of content of the previous nodepointed to by an edge connecting those nodes 1108, a state root value1110 for a trie of cryptographic hash values that may be referred to asa state trie 1118, a cryptographic hash 1112 that is a root value of areceipt trie 1124 of cryptographic hash values referred to as a receipttrie, and a cryptographic hash value 1114 that is a root value of a trieof cryptographic hash values referred to as a transaction trie 1122. Insome embodiments, the block 1104 may be connected to a plurality oftries (e.g., three or more tries) via cryptographic hash pointers. Forexample, the block 1104 may be connected to Merkle roots (or otherroots) of the plurality of tries of cryptographic hash values.

In some embodiments, the state trie 1118 may include multiple levels ofcryptographic hash pointers that expand from a root to leaf nodesthrough 2 or more (e.g. 3, 11, 5, 6, etc.) hierarchical levels ofbranching. In some embodiments, an account address of a smart contractor instance of invocation thereof may correspond to a leaf nodes, wherethe smart contract may be an instance of the smart contract described inone or more operations of one or more processes described in thisdisclosure. In some embodiments, leaf nodes or paths to the leaf nodesof the state trie 1118 may include the fields in the account object1126. The address may be a smart contract address or instance ofinvocation of the smart contract, the nonce value may be a count of thetimes that the smart contract was invoked, the code hash value may be orotherwise include a cryptographic hash of a bytecode representation ofthe smart contract 1130, the storage hash may be a root (e.g. Merkleroot) of a trie of cryptographic hash pointers 1120. In someembodiments, the trie of cryptographic hash pointers 1120 may storekey-value pairs encoding a transient program state of the smart contractthat changes or is not needed between invocations of the smart contract.In some embodiments, the fields of the account object 1126 may include apredecessor pointer that points to a previous entry of an earlier statetrie corresponding to a previous invocation of the smart contract andassociated information or hashes.

FIG. 12 depicts an example logical and physical architecture of anexample of a decentralized computing platform in which a data store ofor process of this disclosure may be implemented, in accordance withsome embodiments of the present techniques. In some embodiments, theremay be no centralized authority in full control of a decentralizedcomputing platform 1200. The decentralized computing platform 1200 maybe executed by a plurality of different peer computing nodes 1202 viathe ad hoc cooperation of the peer computing nodes 1202. In someembodiments, the plurality of different peer computing nodes 1202 mayexecute on a single computing device, such as on different virtualmachines or containers of a single computing device. Alternatively, orin addition, the plurality of different computing nodes 1202 may executeon a plurality of different computing devices, where each computingdevice may execute one or more of the peer computing nodes 1202. In someembodiments, the decentralized computing platform 1200 may be apermissionless computing platform (e.g., a public computing platform),where a permissionless computing platform allows one or more variousentities having access to the program code of the peer node of thepermissionless computing platform to participate by using the peer node.

In some embodiments, the decentralized computing platform 1200 may beprivate, which may allow a peer computing node of the decentralizedcomputing platform 1200 to authenticate itself to the other computingnodes of the decentralized computing platform 1200 by sending a valuebased on a private cryptographic key, where the private cryptographickey may be associated with a permissioned tenant of the decentralizedcomputing platform 1200. While FIG. 12 shows five peer computing nodes,commercial embodiments may include more computing nodes. For example,the decentralized computing platform 1200 may include more than 10, morethan 100, or more than 1000 peer computing nodes. In some embodiments,the decentralized computing platform 1200 may include a plurality oftenants having authentication credentials, wherein a tenant havingauthentication credentials may allow authorization of its correspondingpeer nodes for participation in the decentralized platform 1200. Forexample, the plurality of tenants may include than 2, more than 12, morethan 10, more than 120, more than 100, or more than 1000 tenants. Insome embodiments, the peer computing nodes 1202 may be co-located on asingle on-premise location (e.g., being executed on a single computingdevice or at a single data center). Alternatively, the peer computingnodes 1202 may be geographically distributed. For example, the peercomputing nodes 1202 may be executing on devices at different datacenters or on devices at different sub-locations of an on-premiselocation. In some embodiments, distinct subsets of the peer nodes 1202may have distinct permissions and roles. In some cases, some of the peernodes 1202 may operate to perform the deserialization operations, graphupdate operations, or reserialization operations as described in thisdisclosure.

FIG. 13 shows an example of a computer system by which the presenttechniques may be implemented in accordance with some embodiments.Various portions of systems and methods described herein, may include orbe executed on one or more computer systems similar to computer system1300. Further, processes (such as those described for FIGS. 1, 3, orother figures of this disclosure) and modules described herein may beexecuted by one or more processing systems similar to that of computersystem 1300.

Computer system 1300 may include one or more processors (e.g.,processors 1310 a-1310 n) coupled to System memory 1320, an input/outputI/O device interface 1330, and a network interface 1340 via aninput/output (I/O) interface 1350. A processor may include a singleprocessor or a plurality of processors (e.g., distributed processors). Aprocessor may be any suitable processor capable of executing orotherwise performing instructions. A processor may include a centralprocessing unit (CPU) that carries out program instructions to performthe arithmetical, logical, and input/output operations of computersystem 1300. A processor may execute code (e.g., processor firmware, aprotocol stack, a database management system, an operating system, or acombination thereof) that creates an execution environment for programinstructions. A processor may include a programmable processor. Aprocessor may include general or special purpose microprocessors. Aprocessor may include one or more microcontrollers. A processor mayreceive instructions and data from a memory (e.g., System memory 1320).Computer system 1300 may be a uni-processor system including oneprocessor (e.g., processor 1310 a), or a multi-processor systemincluding any number of suitable processors (e.g., 1310 a-1310 n).Multiple processors may be employed to provide for parallel orsequential execution of one or more portions of the techniques describedherein. Processes, such as logic flows, described herein may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating corresponding output. Processes described herein may beperformed by, and apparatus can also be implemented as, special purposelogic circuitry, e.g., an FPGA (field programmable gate array) or anASIC (application specific integrated circuit). Computer system 1300 mayinclude a plurality of computing devices (e.g., distributed computersystems) to implement various processing functions.

I/O device interface 1330 may provide an interface for connection of oneor more I/O devices 1360 to computer system 1300. I/O devices mayinclude devices that receive input (e.g., from a user) or outputinformation (e.g., to a user). I/O devices 1360 may include, forexample, graphical user interface presented on displays (e.g., a cathoderay tube (CRT) or liquid crystal display (LCD) monitor), pointingdevices (e.g., a computer mouse or trackball), keyboards, keypads,touchpads, scanning devices, voice recognition devices, gesturerecognition devices, printers, audio speakers, microphones, cameras, orthe like. I/O devices 1360 may be connected to computer system 1300through a wired or wireless connection. I/O devices 1360 may beconnected to computer system 1300 from a remote location. I/O devices1360 located on remote computer system, for example, may be connected tocomputer system 1300 via a network and network interface 1340.

Network interface 1340 may include a network adapter that provides forconnection of computer system 1300 to a network. Network interface 1340may facilitate data exchange between computer system 1300 and otherdevices connected to the network. Network interface 1340 may supportwired or wireless communication. The network may include an electroniccommunication network, such as the Internet, a local area network (LAN),a wide area network (WAN), a cellular communications network, or thelike.

System memory 1320 may be configured to store program instructions 1324or data 1315. Program instructions 1324 may be executable by a processor(e.g., one or more of processors 1310 a-1310 n) to implement one or moreembodiments of the present techniques. Program instructions 1324 mayinclude modules of computer program instructions for implementing one ormore techniques described herein with regard to various processingmodules. Program instructions may include a computer program (which incertain forms is known as a program, software, software application,script, or code). A computer program may be written in a programminglanguage, including compiled or interpreted languages, or declarative orprocedural languages. A computer program may include a unit suitable foruse in a computing environment, including as a stand-alone program, amodule, a component, or a subroutine. A computer program may or may notcorrespond to a file in a file system. A program may be stored in aportion of a file that holds other programs or data (e.g., one or morescripts stored in a markup language document), in a single filededicated to the program in question, or in multiple coordinated files(e.g., files that store one or more modules, sub programs, or portionsof code). A computer program may be deployed to be executed on one ormore computer processors located locally at one site or distributedacross multiple remote sites and interconnected by a communicationnetwork.

System memory 1320 may include a tangible program carrier having programinstructions stored thereon. A tangible program carrier may include anon-transitory, computer-readable storage medium. A non-transitory,computer-readable storage medium may include a machine readable storagedevice, a machine readable storage substrate, a memory device, or anycombination thereof. Non-transitory, computer-readable storage mediummay include non-volatile memory (e.g., flash memory, ROM, PROM, EPROM,EEPROM memory), volatile memory (e.g., random access memory (RAM),static random access memory (SRAM), synchronous dynamic RAM (SDRAM)),bulk storage memory (e.g., CD-ROM and/or DVD-ROM, hard-drives), or thelike. System memory 1320 may include a non-transitory, computer-readablestorage medium that may have program instructions stored thereon thatare executable by a computer processor (e.g., one or more of processors1310 a-1310 n) to cause the subject matter and the functional operationsdescribed herein. A memory (e.g., System memory 1320) may include asingle memory device and/or a plurality of memory devices (e.g.,distributed memory devices). Instructions or other program code toprovide the functionality described herein may be stored on a tangible,non-transitory, computer-readable media. In some cases, the entire setof instructions may be stored concurrently on the media, or in somecases, different parts of the instructions may be stored on the samemedia at different times.

I/O interface 1350 may be configured to coordinate I/O traffic betweenprocessors 1310 a-1310 n, System memory 1320, network interface 1340,I/O devices 1360, and/or other peripheral devices. I/O interface 1350may perform protocol, timing, or other data transformations to convertdata signals from one component (e.g., System memory 1320) into a formatsuitable for use by another component (e.g., processors 1310 a-1310 n).I/O interface 1350 may include support for devices attached throughvarious types of peripheral buses, such as a variant of the PeripheralComponent Interconnect (PCI) bus standard or the Universal Serial Bus(USB) standard.

Embodiments of the techniques described herein may be implemented usinga single instance of computer system 1300 or multiple computer systems1300 configured to host different portions or instances of embodiments.Multiple computer systems 1300 may provide for parallel or sequentialprocessing/execution of one or more portions of the techniques describedherein.

Those skilled in the art will appreciate that computer system 1300 ismerely illustrative and is not intended to limit the scope of thetechniques described herein. Computer system 1300 may include anycombination of devices or software that may perform or otherwise providefor the performance of the techniques described herein. For example,computer system 1300 may include or be a combination of acloud-computing system, a data center, a server rack, a server, avirtual server, a desktop computer, a laptop computer, a tabletcomputer, a server device, a client device, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a vehicle-mounted computer, or a GPS device, or the like.Computer system 1300 may also be connected to other devices that are notillustrated, or may operate as a stand-alone system. In addition, thefunctionality provided by the illustrated components may in someembodiments be combined in fewer components or distributed in additionalcomponents. Similarly, in some embodiments, the functionality of some ofthe illustrated components may not be provided or other additionalfunctionality may be available.

Those skilled in the art will also appreciate that while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described in thisdisclosure. In some embodiments, instructions stored on acomputer-accessible medium separate from computer system 1300 may betransmitted to computer system 1300 via transmission media or signalssuch as electrical, electromagnetic, or digital signals, conveyed via acommunication medium such as a network or a wireless link. Variousembodiments may further include receiving, sending, or storinginstructions or data implemented in accordance with the foregoingdescription upon a computer-accessible medium. Accordingly, the presenttechniques may be practiced with other computer system configurations.

In some embodiments, additional operations may be performed to determineoutcome scores, determine counterparty actions, update a directed graph,or retrieve data from a directed graph. Some embodiments may performsuch operations or other operations using methods or systems describedin the co-pending PCT application bearing attorney docket number“053173-0515078” titled “GRAPH-MANIPULATION BASED DOMAIN-SPECIFICEXECUTION ENVIRONMENT,” PCT application bearing attorney docket number“053173-0515079” titled “GRAPH OUTCOME DETERMINATION IN DOMAIN-SPECIFICEXECUTION ENVIRONMENT,” PCT application bearing attorney docket number“053173-0515080” titled “MODIFICATION OF IN-EXECUTION SMART CONTRACTPROGRAMS,” and PCT application bearing attorney docket number053173-0515081 titled “GRAPH EVOLUTION AND OUTCOME DETERMINATION FORGRAPH-DEFINED PROGRAM STATES,” which were filed on 2020 Sep. 8 andassigned to the applicant, “Digital Asset Capital, LLC,” and which areherein incorporated by reference. Some embodiments may further performoperations such as scoring entities, using hybrid systems to efficientlyquery data, determine outcome data based on an event with respect tomultiple directed graphs. Some embodiments may perform such operationsor other operations using methods or systems described in the co-pendingUS patent application bearing attorney docket number “053173-0515218”titled “EVENT-BASED ENTITY SCORING IN DISTRIBUTED SYSTEMS,” US patentapplication bearing attorney docket number “053173-0515223” titled“CONFIDENTIAL GOVERNANCE VERIFICATION FOR GRAPH-BASED SYSTEM,” US patentapplication bearing attorney docket number “053173-0515224” titled“HYBRID DECENTRALIZED COMPUTING ENVIRONMENT FOR GRAPH-BASED EXECUTIONENVIRONMENT,” and US patent application bearing attorney docket number053173-0515226 titled “MULTIGRAPH VERIFICATION,” which were filed on2020 Sep. 8, and are assigned to the applicant, “Digital Asset Capital,LLC,” and which are herein incorporated by reference. Some embodimentsmay perform operations such as dimensionally reducing graph data,querying a data structure to obtain data associated with a directedgraph, perform transfer learning operations, or efficiently notifyentities. Some embodiments may perform such operations or otheroperations using methods or systems described in the co-pending USpatent application bearing attorney docket number “053173-0508429”titled “GRAPH-BASED PROGRAM STATE NOTIFICATION,” US patent applicationbearing attorney docket number “053173-0508434” titled “DIMENSIONALREDUCTION OF CATEGORIZED DIRECTED GRAPHS,” US patent application bearingattorney docket number “053173-0508433” titled “QUERYING GRAPH-BASEDMODELS,” and US patent application bearing attorney docket number“053173-0508438” titled “ADAPTIVE PARAMETER TRANSFER FOR LEARNINGMODELS,” which were filed on 2020 Sep. 8, and are assigned to theapplicant, “Digital Asset Capital, LLC,” and which are hereinincorporated by reference.

As described above, some embodiments may predict an outcome score basedon program state data. However, some embodiments may permit an entity toobfuscate information specific to the entity to protect entity privacy.Some embodiments may satisfy the privacy concerns of a first entitywhile still providing useful scoring mechanisms for other partiesinterested about the first entity based on event information or otherinformation by performing one or more of the operations describedfurther below.

Event-Based Entity Scoring in Distributed Systems

Interactions between a pair of entities in a network of smart contractprograms often rely on the ability of the first of the pair to predictthe behavior of the second of the pair. Some entities may be able to useentity scores calculated from arithmetic operations to make suchpredictions, such as entity scores determined as a ratio of satisfiedobligations to failed obligations. As described in this disclosure, usesof the term “smart contract” are provided for illustrative purposes, andother types of self-executing protocols may be used in place of a smartcontract unless otherwise stated. Such entity scores may be insufficientto predict entity behavior. In some cases, the norm vertices and programstates of a smart contract program may cause an entity to behave in waysthat would not be easily captured using entity scores that do notconsider specific past behaviors or environmental changes. Variousbehaviors and program state features may be used to indicate possiblepatterns in a graph structure. However, the number of the possiblepermutations of a directed graph and its associated program state (whichmay be more than a thousand, more than a million, or more than abillion) may prevent a significant portion of possible features frombeing used to determine an entity score. Furthermore, direct use ofentity scores may be infeasible in environments where an entityparticipating in a smart contract program may only be willing toparticipate if they are able to obfuscate certain values or parametersfrom other participants of the smart contract program or other possibleobservers.

Some embodiments may determine an outcome score associated with abehavior representable by a directed graph of a smart contract program(or other symbolic AI model) based on another behavior indicated by agraph portion of the directed graph or a program state of the smartcontract program. These outcome scores may be used to predict how anentity may behave in, such as whether the entity is likely to accept aset of conditional statements, demand additional conditional statements,satisfy a set of conditional statements, or fail the set of conditionalstatements. These outcome scores may also be used to characterize anentity and determine one or more entity scores for the entity, where anentity score may be equal to an outcome score or be otherwise based onthe outcome score. Some embodiments may use the outcome score or entityscore to determine which rights norms the entity may exercise orprohibition norms the entity may violate.

Some embodiments may obtain the directed graph of the smart contractprogram. Some embodiments may determine whether the directed graphincludes a graph portion that matches a graph portion template. Someembodiments may determine that a match occurs between a graph portionand a graph portion template by comparing the category labels of thenorm vertices of the graph portion and the category labels of the normvertex templates of the graph portion template. Determining a match mayalso include a comparison between other values of the graph portion andthe graph portion template, such as a condition satisfaction state, atransaction score, a set of participating entities, or the like. Anoutcome score of the first entity associated with an outcome programstate or an outcome vertex of the first entity may be determined basedon a determination of a match between a graph portion of a directedgraph and a graph portion template, where the graph portion template maybe associated with the first entity.

In some embodiments, the graph portion template may be stored in orassociated with an entity profile of the first entity. Alternatively, orin addition, the graph portion template may be stored in a generallibrary of graph portion templates and used to determine a set ofoutcome scores for each entity in a set of smart contract programs ortype of entity in the set of smart contract programs (e.g., used todetermine outcome scores for all entities having a particular role). Byusing matching graph portions with stored graph portion templates, someembodiments may provide greater context-dependent predictions whendetermining outcome scores associated with a decision or program stateof an entity and their associated entity score(s) for the entity.

In some embodiments, each respective entity vertex of an entity graphmay include or otherwise be associated with a respective entity profile.In some embodiments, the entity graph and entity profiles may be storedin the same data structure. For example, each entity profile may be usedas an entity vertex of an entity graph or otherwise be associated withthe entity vertex of the entity graph.

FIG. 14 depicts a diagram of an entity graph, in accordance with someembodiments of the present techniques. An entity graph 2200 may includea set of vertices (“entity vertices”) and edges associating the entityvertices, where the entity vertices may include or otherwise beassociated with a first entity profile 2210, a second entity profile2220, a third entity profile 2240, and a fourth entity profile 2250. Insome embodiments, each respective entity vertex of the entity graph 2200may include or otherwise be associated with a respective entity profile.In some embodiments, the entity graph and entity profiles may be storedin the same data structure. For example, each entity profile may be usedas an entity vertex of an entity graph or otherwise be associated withthe entity vertex of the entity graph. The entity profiles of the entitygraph 2200 may be stored in a storage memory of a computing device. Forexample, the entity profiles of the entity graph 2200 may be stored asobjects, lists, trees, or the like. While FIG. 2 depicts the entitygraph as comprising entity profiles directly, some embodiments mayinstead generate or otherwise update an entity graph comprising entityvertices that include values other than those included in an entityprofile or include a reference to the entity profile. In someembodiments, an entity graph may be used to determine relationships,events, types of transactions, transaction scores, or the like betweendifferent entities.

The box 2212 includes a dictionary encoding a graph portion templatethat can be visualized in a form represented in the dashed box 2270. Asshown in the box 2212, a dictionary encoding the graph portion templatemay include a first key “name” with a corresponding value “subgraph1” toindicate that the graph portion template has a name “subgraph1.” Thedictionary encoding the graph portion template in box 2212 may alsoinclude a second key “vertex types” and a corresponding value equal to asubdictionary, where each key of the sub dictionary may include a numberand each value of the subdictionary may include a vertex property list.As shown in the box 2212, the vertex property list corresponding to thenorm vertex template having the index value of “0” may be equal to [“0”,“Failed”]. The first value of the vertex property list may indicate thecategory label “0” (which may represent an “obligation” category)associated with the first norm vertex template and the second value ofthe property list may indicate a state of the first norm vertextemplate.

In some embodiments, a category label of a norm vertex template may besimilar to or the same as those assigned to one or more norm vertices,such as “obligation,” “right,” or “prohibition.” Furthermore, someembodiments may use other characters to represent a category label. Forexample, The letters “0,” “R,” and “P” shown in FIG. 22 and used as partof the vertex property list shown in the box 2212, the box 2222, the box2224, or the box 2242 may be associated with category labels such as“obligation,” “rights,” and “prohibitions,” respectively. In someembodiments, the set of category labels may include a set of mutuallyexclusive category labels. For example, if the set of mutually exclusivecategory labels includes the category labels “obligation,” “right,” and“prohibition,” a norm vertex template categorized as being an“obligation” norm may not be categorized as being a “prohibition” norm.As further discussed below, the use of mutually exclusive categorylabels can increase the speed and reliability of a matching operationbetween a graph portion and a graph portion template.

The dictionary shown in box 2212 may also include a third key “edgetemplate” and the corresponding value of the third key “edge template”may include an array of subarrays, where each subarray may represent anedge template from a first norm vertex template to a second norm vertextemplate. An edge of a directed graph may be matched with an edgetemplate if the head and tail of the edge match. In some embodiments,the order of the values in each subarray may indicate a directionalityof the edge. For example, the subarray “[0,1]” may represent an edgeassociating the first norm vertex template represented by the key-valuepair “[0: [“O”, “Failed”]]” to the second norm vertex templaterepresented by the key-value pair “[1: [“R”, “Failed”]],” where the edgemay have an edge direction from the first norm vertex template to thesecond norm vertex template.

The dictionary shown in box 2212 may also include a fourth key“out_det_param,” where a corresponding value of the fourth key mayinclude a set of outcome determination parameters or values otherwiseassociated with the outcome determination parameters. As describedfurther below, some embodiments may determine an outcome determinationparameter of a graph portion template using various methods such as bycalculating a ratio of a first number to a second number, by computing aratio of weighted sums, by training a machine learning model, or thelike. In some embodiments, the outcome determination parameter of agraph portion template may be equal to correlated with a predictedlikelihood of a particular outcome occurring.

In some embodiments, the set of outcome determination parameters mayinclude a value to specify a type of outcome determination operation touse. For example, the set of outcome determination parameters of the box2212 include the list ‘[“CNN”, “Satisfy”, “x1110”].’ The first elementof the set of outcome determination parameters may be an identifier ofan outcome determination model usable by a computing system to selectthe outcome determination model. For example, the value “CNN” may causea computing system to select a convolutional neural network to determinean outcome score. The second element of the list used as a value for thefourth key “out_det_param” may indicate an outcome state associated withthe outcome score being computed by a selected model. For example, thesecond element of the list [“CNN”, “Satisfy”, “x1110”]’ may include thephrase “Satisfy,” which may indicate that the outcome score represents alikelihood of the first entity to satisfy an obligation. The value“x1110” may indicate a record in a database of model parameters, wherethe record may include weights, biases, hyperparameters, or other valuesof the outcome determination model used to determine an outcome score.

FIG. 14 depicts a diagram of an entity graph, in accordance with someembodiments of the present techniques. The directed graph enclosed bythe dashed box 2270 may match the graph portion template encoded in box2212. Some embodiments may determine that the first norm vertex 2271matches the norm vertex template represented by the first key-value pair“0:[“O”, “Failed”].’ This determination may be based on the “obligation”label of the first norm vertex matching the “O” (which may be used torepresent an “obligation” norm) of the second key-value pair and thefailed state of the first norm vertex 2271 matching the “Failed” stateof the first key-value pair. Similarly, some embodiments may determinethat the second norm vertex 2273 matches the norm vertex templaterepresented by the second key-value pair ‘1:[“R”, “Failed”].’ Thisdetermination may be based on the rights norm label of the second normvertex matching the “R” of the second key-value pair and the failedstate of second norm vertex 2273 matching the “Failed” state of thesecond key-value pair. Some embodiments may determine that the thirdnorm vertex 2275 matches the norm vertex template represented by thethird key-value pair ‘2:[“R”,].’ This determination may be based on therights norm label of the second norm vertex matching the “R” of thesecond key-value pair.

As shown in the dashed box 2270, the first norm vertex 2271 may beassociated with the second norm vertex 2273 via the directed graph edge2272, and the second norm vertex 2273 may be associated with the thirdnorm vertex 2275 via the directed graph edge 2274. A determination maybe made that a directed graph edge matches with an edge template. Thisdetermination may be based on the head vertex of the directed graph edgematching with a corresponding vertex template that the edge template isdirected away from and the tail vertex of the directed graph edgematching with a corresponding vertex template that the edge template isdirected towards.

For example, some embodiments may determine that the directed graph edge2272 may match the edge template subarray ‘[0,1]’ displayed in the box2212. This determination may be made based on the tail of the directedgraph edge 2272 being the first norm vertex 2271, which matches with thenorm vertex template represented by “0:[“O”, “Failed”],’ and may also bebased on the head of the directed graph edge 2272 being the second normvertex 2273, which matches with the norm vertex template represented by“1:[“R”, “Failed”],” where the edge template subarray [0,1] directs awayfrom the first and towards the norm vertex template represented by“1:[“R”, “Failed”].” Similarly, some embodiments may determine that thedirected graph edge 2274 may match the edge template subarray ‘[1,2]’displayed in the box 2212. This determination may be made based on thetail of the directed graph edge 2274 being the second norm vertex 2273,which matches with the norm vertex template represented by “1:[“R”,“Failed”]” and may also be based on the head of the directed graph edge2274 being the third norm vertex 2275, which matches with the normvertex template represented by “2: [“R”],” where the edge templatesubarray [0,1] directs away from the norm vertex template represented by“1:[“R”, “Failed”] and towards the norm vertex template represented by“2:[“R”].”

Some embodiments may determine that a graph portion template matcheswith a graph portion(s) of a smart contract directed graph. In response,these embodiments may further provide one or more norm vertexidentifiers corresponding to the position of the graph portion in thesmart contract program directed graph. For example, a graph portion of adirected graph that includes the first norm vertex 2271, second normvertex 2273, and third norm vertex 2275 may be matched with a graphportion template. In response, some embodiments may provide anidentifier for the first norm vertex 2271, second norm vertex 2273, orthird norm vertex 2275 in association with the graph portion template.

In some embodiments, the entity graph 2200 may include an associationbetween the first entity profile 2210 and the second entity profile2220, where the association may include an entity graph edge. Forexample, the first entity profile 2210 may be associated with the secondentity profile 2220 via a first entity graph edge 2216 and a secondentity graph edge 2217. In some embodiments, the associations betweenentities an entity graph may be treated as edges having a directionalityor may be associated with a quantitative or categorical value. Forexample, a first entity graph edge 2216 may be based on a norm vertexassociated with a conditional statement that includes an allocation ofcomputing resources from the first entity “Ent1” to the second entity“Ent2.”

In some embodiments, the entity graph 2200 may include an associationbetween the first entity profile 2210 and the second entity profile2220. For example, the first entity profile 2210 may be associated withthe second entity profile 2220 via a first entity graph edge 2216 and asecond entity graph edge 2217. In some embodiments, the associationsbetween entities an entity graph may be treated as edges having adirectionality or may be associated with a quantitative or categoricalvalue. For example, a first entity graph edge 2216 may be stored as anarray [x01553e51, x022354e88] based on a norm vertex associated with aconditional statement that includes an allocation of computing resourcesfrom the first entity “Ent1” to the second entity “Ent2.” Alternatively,or in addition, the first entity graph edge 2216 or other associationsbetween different entities or between their corresponding profiles maybe stored as pointers or reference identifiers associated with theentities themselves. Furthermore, some embodiments may store a set ofassociations such as a set of entity graph edges in a single record,data object, property, or the like. For example, some embodiments maystore the first entity graph edge 2216 and second entity graph edge 2217in the form of an entity association dictionary [ent1:x01553e51, ent2:x022354e88, RAM: 50, Memory: −300]′ to indicate an association based ona set of transactions or possible transactions between the first entity‘x01553e51’ and the second entity ‘x022354e88.’ The entity associationdictionary may be based on a first conditional statement of anobligation norm that would cause the first entity allocating 50 GB ofRAM from the first entity ‘x01553e51’ to the second entity ‘x022354e88’and a second conditional statement of an obligation norm that wouldcause the first entity allocating 50 GB of RAM from the first entity‘x01553e51’ to the second entity ‘x022354e88.’

In some embodiments, the entity graph 2200 may include an associationbetween the second entity profile 2220 and the third entity profile2240. For example, the entity graph 2200 may include a second set ofassociations that include the third entity graph edge 2228, a fourthentity graph edge 2229, a fifth entity graph edge 2230, and a sixthentity graph edge 2231. In some embodiments, each of the entity graphedges in the second set of associations may have a directionality fromone of the pair of entities to the other of the pair of entities basedon a transfer of data, provided service, allocation of resources, or thelike. In some embodiments, each of the associations may be based on aset of conditional statements for which the corresponding triggeringevent(s) or outcome state(s) affect the pair of entities. For example,the third entity graph edge 2228 may be associated with the transactionscore “100 GB” that is obtained from a conditional statement encodingthe allocation of 100 GB of memory from the second entity associatedwith the second entity profile 2220 to the third entity associated withthe third entity profile 2240.

In some embodiments, the entity graph 2200 may include an associationbetween the first entity profile 2210 and a fourth entity profile 2250.The fourth entity profile 2250 of the entity graph 2200 may represent averification entity that does not have any stored graph portiontemplates. The first entity profile 2210 may be associated with thefourth entity profile 2250 via the set of associations that include anentity graph edge 2218 and an entity graph edge 2219. Similarly, thesecond entity profile 2220 may be associated with the fourth entityprofile 2250 via the set of associations that include an entity graphedge 2226 and an entity graph edge 2227. Similarly, the third entityprofile 2240 may be associated with the fourth entity profile 2250 viathe set of associations that include an entity graph edge 2246 and anentity graph edge 2247. In some embodiments, the entity graph edgesbetween the first, second, or third entity with a verification entitymay represent associations based on messages confirming that an actionor a value has been sent to a fourth entity associated with the fourthentity profile 2250 by one of the respective entities associated withone of the other entity profiles 2210, 2220, or 2240. For example, theentity graph edges 2219, 2227, and 2247 may be based on instructionsencoding the sending of outcome scores or other values to the fourthentity and the entity graph edges 2218, 2226, and 2246 may be based oninstructions encoding the transmission of indicators indicating whetherthe sent scores or other values satisfy a set of criteria. In someembodiments, the entity associated with the fourth entity profile 2250may provide verification that another entity had satisfied a thresholdor other criteria.

Some embodiments may generate an entity graph where each of the entityprofiles associated with the vertices of the entity graph satisfies oneor more criteria. For example, while the entity graph 2200 includes thefourth entity profile 2250, some embodiments may generate an entitygraph based on a first criterion that each entity allocates or receivesallocations of computing resources with at least one other entity. Someembodiments may use this first criterion to generate an entity graphcomprising entity vertices associated with the first entity profile,second entity profile, and third entity profile without including thefourth entity profile 2250.

Some embodiments may determine one or more paths through the entitygraph 2200 to determine a relationship between different entities. Forexample, the first entity “x01553e51” is not shown to have any directassociations with the third entity “x125574f39.” However, someembodiments may determine that the first entity “x01553e51” may beassociated with the third entity “x125574f39” based on a path from thefirst entity “x01553e51” to the third entity “x125574f39” via the firstentity graph edge 2216 and the third entity graph edge 2228. Someembodiments may determine that the first entity graph edge 2216 and thethird entity graph edge 2228 form a path based on a shared resourcetype, a shared combination of resource types, shared range boundingtransaction amounts, or the like.

FIG. 15 is a flowchart of a process to assign an outcome score based ona graph portion, in accordance with some embodiments of the presenttechniques. In some embodiments, the process 2300 may include obtaininga set of smart contract programs, each of which encodes a directedgraph, as indicated in block 2304. Each program of the set of smartcontract programs may similar to those described for block 304. Forexample, the set of smart contract programs may be obtained from acentralized or decentralized computing platform executing a plurality ofsmart contract programs or storing a history of smart contract programs.In some embodiments, the number of smart contract programs may be overfive smart contract programs, over 10 programs, over 50 programs, over100 programs, or the like. For example, some embodiments may obtain over50 smart contract programs, where each respective smart contract programof the plurality of smart contract programs includes data encoding arespective directed graph and encoding a respective set of entitiescapable of viewing or modifying a state of the respective smart contractprogram. In some embodiments, an obtained smart contract program maystill be in operation, where the state of the smart contract programencoding the directed graph may be changed based on received eventmessages. Alternatively, or in addition, an obtained smart contractprogram may be completed and no longer responsive to event messagesreceived by a computing platform. For example, a smart contract programmay be executed to completion, where no further conditional statementsof the smart contract program can be triggered.

In some embodiments, the process 2300 may include determining a firstgraph portion template based on the directed graphs of the set of smartcontract programs, as indicated by block 2308. A graph portion templatemay include one or more norm vertex templates, one or more edgesassociating two norm vertex templates, or the like. A norm vertextemplate may include values associated with a norm vertex such as acategory label, a satisfaction state, a conditional statement, a type ofconditional statement, or the like. For example, the graph portiontemplate may include a category label “obligation” and the satisfactionstate “failed.” As further described below, the norm vertex template maybe used to determine the presence of a norm vertex, where two normvertex templates of a graph portion template may be identical to eachother or different from each other. For example, a norm vertex that isindicated to be an obligation norm that is failed may be matched with afirst norm vertex template in response to the norm vertex templateincluding or otherwise associated with the category label “obligation”and the satisfaction state “failed.” In some embodiments, an edgetemplate associating two norm vertex templates may be directed from afirst norm vertex template to a second norm vertex template. An edgetemplate associating two norm vertex templates may include an arrayspecifying the identifiers of two norm vertex templates, a transactionamount, a range of transaction amounts, or the like.

In some embodiments, the graph portion template may be associated withone or more category labels, conditional statements, or types ofconditional statements. For example, a set of category labels may beused for a set of norm vertex templates and may include mutuallyexclusive category labels. For example, a first graph portion templatemay include a first norm vertex template associated with a firstcategory label, and an edge template may associate the first norm vertextemplate with a second norm vertex template, where the second normvertex template may be associated with a second category label. In someembodiments, a conditional statement may be used to specify a graphportion template. For example, a graph portion template may include aterminal norm vertex associated with a failure to satisfy an obligation.

In some embodiments, the graph portion template may include a first normvertex template and a second norm vertex template that are not connectedto each other in the graph portion template. For example, the first normvertex template may be associated with the category label “obligationnorm” and the second norm vertex template may be associated with thesame category label “obligation,” where the first and second normvertices may represent unrelated obligations of a first entity toallocate resources to a second entity. Alternatively, or in addition,the graph portion template may include a directed path or cycleconnecting a set of norm vertex templates. For example, a first graphportion template may include a first norm vertex template associatedwith a second norm vertex template and a second norm vertex templateassociated with a third norm vertex template. In some embodiments, thegraph portion template may include a combination of single, disconnectednorm vertex templates, directed paths through norm vertex templates,circular paths through norm vertex templates, or the like, where pathsthrough a graph portion template may be determined based on a set ofedge templates.

Some embodiments may determine the first graph portion template based ona library of graph portion templates. For example, the library of graphportions templates may include a graph portion template associated witha first array indicating logical category labels of a subgraph. Variousmethods may be used to determine the presence of a subgraph in a graph.For example, some embodiments may decompose a directed graph into a setof possible subgraphs (“induced graphs”) and determine whether asubgraph is present by comparing each induced graph of the set ofpossible subgraphs with each graph portion template of a set of graphportion templates. In some embodiments, graph portion templates thatmatch one or more induced subgraphs of a directed graph may be includedin the set of graph portion templates used to determine an outcomescore. Furthermore, as discussed further below, a graph portion templatemay be associated with a specific entity or set of entities. Forexample, a graph portion may be stored in an entity profile associatedwith a specific entity. Alternatively, a graph portion template may bestored in a default set of graph portion templates that is used todetermine outcome scores for multiple entities by default.

Some embodiments may use subgraph isomorphism algorithms to determinethe presence of a subgraph in a graph, where a subgraph may be specifiedby a subgraph template. The detection of subgraph isomorphs may includealgorithms that account for the possibility that a candidate subgraph isnot present a graph (e.g., the candidate subgraph is not necessarily aninduced subgraph of the graph) on include algorithms that assume thecandidate subgraph is present (e.g., the candidate subgraph is known tobe an induced subgraph of the graph). Some embodiments may use aplurality of subgraph isomorphism algorithms to determine the presenceof a subgraph based on the subgraph structure itself. For example, someembodiments of may use algorithms to determine the presence ofthree-node subgraphs in a graph, such as algorithms developed by Itaiand Rodeh or Eisenbrand and Grandoni, as described by in “Graph patterndetection” Dalirrooyfard (STOC 2019: Proc. 51st Annual ACM SIGACTSymposium on Theory of Computing, arXiv:1904.03741), which is hereinincorporated by reference.

In some embodiments, the process 2300 may include determining a set ofoutcome determination parameters based on the set of graph portiontemplates, as indicated by block 2312. A set of outcome determinationparameters may be used by an outcome determination model to determine anoutcome score, such as a statistical prediction model, an unsupervisedlearning model, a supervised learning model, some combination thereof,or the like. As further discussed below, the outcome determination modelusing the outcome determination parameters may be used associated withan outcome score and an outcome. An outcome may include an outcomeprogram state, the occurrence of an event, the satisfaction or failureof a payment obligation by an entity, the matching of a graph portionwith a specified graph portion template, or the like.

In some embodiments, an outcome determination parameter may bedetermined using a ratio or a statistical calculation. In someembodiments, an outcome determination parameter may indicate orotherwise be correlated with a number of times that the behaviorindicated by the first graph portion template had occurred. For example,the outcome score may be a ratio of the number of times that the firstgraph portion template matches with a graph portion in the set ofdirected graphs to the number of times that the first entity hadinteracted with another entity based on a plurality of the directedgraphs of a plurality of smart contract programs. In some embodiments,an outcome determination model may be caused to use a specified set ofoutcome determination parameters for a directed graph based on thedirected graph having a graph portion matching a second graph portiontemplate, as discussed further below.

In some embodiments, the outcome determination parameters may include aset of weights, biases, or other parameters of a neural network model oranother machine-learning model. Some embodiments may determine a set ofoutcome determination parameters for a first entity by training theneural network model or another machine-learning model to use aplurality directed graphs of a plurality of smart contract programsassociated with the first entity. For example, the set of outcomedetermination parameters may include a set of neural network weights ofone or more neurons of a convolutional neural network or other neuralnetwork, The convolutional neural network or other neural network may beused to determine a likelihood of an outcome action occurring, where theoutcome action may include a transition to an outcome program state, anevent occurring, or the like. In some embodiments, the neural networkmay be trained to use the match between a graph portion and a graphportion template as a feature. For example, some embodiments may betrained using a feature that is set to “1” when a directed graph has agraph portion that matches a first graph portion template and is set to“0” when the graph portion does not match the first graph portion.Additionally, or alternatively, the feature set may include otherattributes such as global parameter values of the smart contract programstate, variables stored in a storage memory accessible to the smartcontract program, or the like.

In some embodiments, the feature set used to train a neural networkmodel or other machine-learning model to determine outcome determinationparameters based on a directed graph may include embeddings based on thedirected graph. Some embodiments may encode the entity vertices of anentity graph to determine a feature set, such as by applying anembedding algorithm such as a one-hot encoding algorithm to a set ofentity vertices. In some embodiments, the embedding assigned to arespective vertex of the directed graph may include or otherwise beassociated with a relationship between the respective entity and otherentities of the entity graph. For example, some embodiments may generatea set of entity graph features using a vertex embedding algorithm suchas using a random walk algorithm, a neural network-based embeddingalgorithm, or the like. For example, some embodiments may generate a setof embeddings for the vertices of a directed graph using a random walkalgorithm such as a DeepWalk algorithm, a Node2Vec algorithm, or thelike. Use of a random walk algorithm may include performing random walksampling for each vertex of the directed graph, training a skip-grammodel by using the random walks as one-hot vectors and computing anembedding based on an output of the trained skip-gram model.

Alternatively, or in addition, some embodiments may generate the set ofentity graph features using a neural network-based algorithm such as astructural deep network embedding (SDNE) algorithm. For example, someembodiments may use a set of autoencoders that may take a node adjacencyvector as an input and is trained to reconstruct the node adjacencyvector based on a second-order adjacency. The adjacency vector of avertex may be represented as a vector where non-zero elements representa connection between the vertex and other vertices a graph. Afirst-order adjacency vector for a first vertex may represent theadjacency vector for the first vertex itself, and a second-orderadjacency vector of the first vector may represent the adjacency vectorfor a neighboring vertex of the first vertex. Some embodiments may usethe adjacency vectors of a directed graph vertex as a set of embeddingsfor the directed graph or otherwise determine the set of embeddingsbased on the adjacency vector outputs of the set of autoencoders. Whilethe above describes the use of random walk algorithms or neuralnetwork-based algorithms to generate a set of embeddings, various otheralgorithms or methods may be used to determine embeddings for a graph.For example, some embodiments may use a graph factorization embeddingalgorithm, GraRep embedding algorithm, locally linear embeddingalgorithm, laplacian eigenmaps embedding algorithm, high-order proximitypreserved embedding algorithm, deep network embedding for graphrepresentation embedding algorithm, graph convolutional neural networkembedding algorithm, graph2vec algorithm, or the like.

In some embodiments, a set of features used to train an outcomedetermination model for a first entity may include data encoding orotherwise representing statuses of other entities of an entity graphthat includes the first entity. For example, a feature used by anoutcome determination model for a first entity may include or be basedon a feature matrix representing whether other entities of the entitygraph have been failed by the first entity. Alternatively, or inaddition, a feature may include an entity graph feature that indicates aconnectedness of the graph to a specific entity, a global parameter notspecific to an entity (e.g., an index stock price, a system temperaturevalue, or the like), or the like. For example, some embodiments may usethe graph2vec algorithm, which may include sampling a set of entitysubgraphs in an entity graph, training a skip-gram model based on theset of entity subgraphs, and determining entity embeddings based on thetrained skip-gram model. Some embodiments may then train a neuralnetwork model using the set of entity embeddings to determine an outcomedetermination parameter.

In some embodiments, a feature used for training or using a machinelearning model may include or be based on a set of transaction amountsindicating an amount that has been transferred to or from a respectiveentity associated with respective entity vertex with respect to each ofthe other entities that have had a transaction with the respectiveentity. Alternatively, or in addition, the feature may include or bebased on a count of transactions that had occurred between therespective entity and other entities of an entity graph. For example, afeature for training or using a machine-learning model associated with afirst entity may include a ratio of the number of times that the firstentity had failed an obligation norm when dealing with a second entityto a number of times that the first entity had a transaction with thesecond entity. Alternatively, or in addition, this ratio or anothervalue based on a count of transactions may be used as an outcomedetermination parameter.

In some embodiments, the process 2300 may include obtaining a firstdirected graph of smart contract program of a first entity, as indicatedby block 2320. Operations to obtain the directed graph of the smartcontract program of the first entity may include obtaining a directedgraph from a storage memory by querying a database, retrieving programstate data, or the like.

In some embodiments, the process 2300 may include obtaining a set ofgraph portion templates based on the first entity, as indicated by block2324. Some embodiments may obtain the graph portion templates byobtaining an entity profile of an entity, where the entity profileincludes or is otherwise associated with graph portion templates. Asdiscussed above, the set of graph portion templates may be determinedbased on a set of smart contract programs associated with the firstentity. In some embodiments, an entity profile may include an entityidentifier, a set of values indicating one or more attributes associatedwith an entity, a set of entity scores, or the like. For example, anentity profile may include a set of display names, set of internalalphanumeric identifiers o the entity, set of numeric values orcategories indicating behaviors, a set of numeric values or categoriesindicating limits or numeric ranges, or the like. Some embodiments maystore a set of graph portion templates in an entity profile or otherwiseassociate the graph portion template with the entity profile. Forexample, some embodiments may store the display name “entity 553,” theentity role name “resource allocator,” a maximum resource allocationlimit “106 GB,” and a set of graph portion templates in the first entityprofile. In some embodiments, a single entity may be associated withmore than one entity profile. Alternatively, or in addition, the set ofgraph portion templates may be obtained from a library of graph portiontemplates that is either not associated with an entity profile or isassociated with multiple entity profiles. For example, some embodimentsmay obtain a default set of graph portion templates to determine anoutcome score for a first entity from a library of graph portiontemplates that is not stored in an entity profile of the first entity.

In some embodiments, the process 2300 may include determining a set ofoutcome scores based on the first directed graph of the first entity,the set of outcome determination parameters, or the set of graph portiontemplates, as indicated by block 2332. As described above, someembodiments may load or otherwise obtain a set of outcome determinationparameters and use the obtained outcome determination parameters todetermine an outcome score using an outcome determination model. Theselection of an outcome determination model and its corresponding set ofoutcome determination parameters may be based on values stored in anentity profile of a first entity or otherwise based on values associatedwith the first entity. For example, a first entity profile may include aplurality of sets of outcome determination parameters, where each set ofthe plurality of sets causes the use of a respective outcomedetermination model and a respective set of outcome determinationparameters for the respective outcome determination model.

The outcome determination model may include a model for determiningpredictions or the likelihood of an outcome such as a statistical model,a machine learning model, or the like. The outcome may include variouspossible outcomes, such as the satisfaction or failure of an obligationby an entity, the activation of a vertex having a specified categorylabel, or the like. For example, some embodiments may determine that afirst set of outcome determination parameters stored in an entityprofile associated with a first entity specifies the use of aconvolutional neural network as an outcome determination model. Someembodiments may then use a weights array identifier stored in the set ofoutcome determination parameters to obtain a set of weights and biasesfrom a database of parameters. Some embodiments may then use the set ofweights and biases for the convolutional neural network to determine anoutcome score, where another value stored in the set of outcomedetermination parameters may indicate that the outcome score includes ameasurement of the likelihood that the first entity will fail anobligation.

As described above, determining the outcome score may includedetermining whether a graph portion of the first directed graph matchesa graph portion template of the set of graph portion templates. Someembodiments may use one or more graph isomorphism algorithms todetermine whether a graph portion matches a template of the set of graphportion templates. In response to a determination that a match exists,some embodiments may update an input value of the outcome determinationmodel, where the input value indicates that the graph portion matches agraph portion template. Some embodiments may then determine an outcomescore based on the input value. For example, some embodiments may obtaina count of the number of times that the graph portion template matches agraph portion of the directed graph and use the count as an input valuefor a machine learning model to determine an outcome score. In someembodiments, the set of graph portion templates stored in the entityprofile of a first entity or otherwise associated with the first entitymay include a norm vertex template, an edge between norm vertextemplates, a path through a plurality of vertex templates, or the like.Furthermore, in some embodiments, the outcome score may be one of a setof outcome scores, where each score of the set of outcome scores isdetermined using one of a set of outcome determination parameters.

In some embodiments, the process 2300 may include determining whetherthe outcome score satisfies an outcome score threshold, as indicated byblock 2340. In some embodiments, the outcome score threshold may includea predetermined value. For example, an outcome score may indicate thelikelihood that the first entity participates in a smart contract thatincludes a directed graph having a specified graph portion that matchesa target graph portion template. For example, the outcome scorethreshold may be equal to 50%, and satisfying the outcome scorethreshold may indicate that at least 50% of the smart contracts in whichthe first entity participates include a directed graph having a graphportion that matches a target graph portion template. In someembodiments, each entity may include a plurality of outcome scores,where each of the plurality of outcome scores may have a correspondingoutcome score threshold. If the outcome score satisfies the outcomescore threshold, operations of the process 2300 may proceed tooperations described for block 2344. Otherwise, operations of theprocess 2300 may proceed to operations described for block 2348.

In some embodiments, the process 2300 may include storing a valueindicating that the outcome score threshold is satisfied, as indicatedby block 2344. The value indicating that the outcome score threshold issatisfied may be stored in various forms. For example, the valueindicating outcome score threshold satisfaction may include a booleanvalue, a number representing that the outcome score threshold issatisfied, an alphanumeric string such as “satisfied,” a value of adictionary or object property, or the like. As discussed further below,the value indicating outcome score threshold satisfaction may be storedin an entity profile, a database of values, or some other data structurestored on persistent computer memory. In some embodiments, the value maybe stored on a tamper-evident, distributed ledger operating on adistributed computing platform. Alternatively, or in addition, the valuemay be stored on a centralized computing platform, such as on a singlecomputing device. Furthermore, as described elsewhere in thisdisclosure, updating the value indicating outcome score thresholdsatisfaction may include updating an entity graph.

In some embodiments, the process 2300 may include updating an entityscore based on the outcome score, as indicated by block 2348. Variousmethods may be used to determine an entity score based on the outcomescore. For example, some embodiments may set an entity score to be equalto an outcome score. Alternatively, or in addition, an entity score maybe equal to a weighted sum of entity scores. For example, someembodiments may determine an entity score to be equal to a set ofoutcome scores equal to a set of probabilities of obligation normfailure multiplied by a corresponding transaction score.

In some embodiments, updating the entity score based on the outcomescore may include updating an entity profile associated with the entitygraph, where the entity profile includes or is otherwise associated withthe entity score. In some embodiments, the values updating an entityprofile of the first entity may then also be used to update additionalentity profiles of other entities of an entity graph. Some embodimentsmay store entity profile values or entity graph values on atamper-evident, distributed ledger operating on a distributed computingplatform. Alternatively, or in addition, the value may be stored on acentralized computing platform, such as on a single computing device.

Furthermore, in some embodiments, the entity score may be used in a setof simulations to determine whether an entity is likely to accept orreject amendments to the conditional statements of a smart contractprogram or the structure of a directed graph of the smart contractprogram. For example, a first outcome score may represent a likelihoodof a first entity to fail an obligation based on a simulation of a firstsmart contract program and a second outcome score may represent alikelihood of the first entity to fail an obligation based on asimulation of a second smart contract program. Based on a comparison ofthe first outcome score and the second outcome score, some embodimentsmay determine the likelihood that a second entity is likely to accept orreject a proposed amendment to a conditional statement used in the firstand second smart contract programs.

FIG. 16 is a flowchart of a process to send a message indicating that anentity score has been updated based on an entity graph, in accordancewith some embodiments of the present techniques. In some embodiments,operations of the process 2400 may include updating an entity graphbased on an outcome score associated with a first entity or a secondentity of the entity graph, as indicated by block 2404. In someembodiments, updating an entity graph may include updating an entityscore of the entity graph based on an outcome score determined using oneor more of the operations described above for the process 2300. Forexample, an entity score for a first entity may be equal to an outcomescore described above. Alternatively, or in addition, an entity scoremay be based on a combination of outcome scores. For example, in someembodiments, an entity score may be equal to a weighted sum of a firstoutcome score based on the number of times the entity fails two or moreobligation norms and a second outcome score based on the number of timesthe entity triggers a rights norm to prematurely terminate a smartcontract program.

In some embodiments, the entity score, entity profile associated withthe entity score, or entity graph associated with the entity score maybe stored on a distributed, tamper-evident ledger of a distributedcomputing platform. For example, a version of a first entity profile, asecond entity profile, and an entity graph edge associating the firstentity profile to the second entity profile may be stored on thedistributed, tamper-evident ledger (e.g., stored as on-chain data).Alternatively, or in addition, some or all of the entity graph may bestored on storage memory that is not part of a distributed,tamper-evident ledger. For example, some embodiments may store datarelated to the entity graph in a storage memory of a centralizedcomputing platform, where the data may be accessible and transferredover a distributed computing platform via a verification hash value. Forexample, some embodiments may update data related to a first entityprofile by transmitting an updated score from a distributed computingplatform to the centralized computing platform. Receiving the updatedscore may cause the centralized computing platform to update the firstentity profile based on the updated score. In some embodiments, theupdated score is not stored in a persistent memory of the distributedcomputing platform and is stored in a persistent memory of thecentralized computing system, where the updates score may be obtainedfrom the centralized computing system using data provided from thedistributed computing platform.

Some embodiments may detect the similarity between two different entityprofiles based on a set of entity similarity criteria. For example, someembodiments may compare a first entity profile and a second entityprofile based on a set of predetermined fields such as an entity name,an account number, an identifier value, entity role, a hashed loginvalue, or the like. Some embodiments may determine a similarity valuebased on a ratio of identical values in the set of predetermined fields.For example, some embodiments may determine that two entity profilesshare a same entity name, a same entity role, and a same accessprivilege and, in response, determine that the two entity profilessatisfy an entity similarity criterion. In some embodiments, thedetermination that two entities satisfy a set of entity similaritycriteria may cause a smart contract program or other symbolic AI programto generate a message indicating the two entity profiles. By indicatingsimilarities between two entity profiles, some embodiments may reducethe risk of hacking attempts, counterfeiting attempts, unnecessaryduplication of roles, or the like.

In some embodiments, operations of the process 2400 may includedetermining whether the first entity failed or satisfied a conditionalstatement associated with the second entity, as indicated by block 2410.In some embodiments, an event message may be obtained by a smartcontract program that triggers a norm vertex associated with the firstentity, where the event message causes the first entity to satisfy orfail a conditional statement associated with the norm vertex. Forexample, a conditional statement may correspond to an obligation normvertex in a set of norm vertices, where a condition of the conditionalstatement may include the condition that the first entity sends anaccount renewal message to the second entity. In response to the firstentity sending the account renewal message to the second entity, someembodiments may determine that the first entity has satisfied theobligation norm vertex. Alternatively, or in addition, an event messagemay be provided by the second entity, a third-party entity, anotherapplication operating on a computing platform executing the smartcontract program or other symbolic AI program, an API of the smartcontract program, or the like. For example, a conditional statement maycorrespond to an obligation norm vertex in a set of norm vertices, wherethe conditional statement may include a condition that the second entitysends a confirmation message indicating that it is able to use computingresource allocated by the first entity or has received a correspondingamount of a digital asset equivalent to the computing resource from thefirst entity. In response to the second entity not sending theconfirmation message, some embodiments may determine that the firstentity has failed a conditional statement associated with the secondentity.

In some embodiments, operations of the process 2400 may include updatingan association between a first entity profile and a second entityprofile, as indicated by block 2414. The association between the firstentity profile the second entity profile may be a part of the entitygraph and may be stored as an entity graph edge associating a firstentity vertex corresponding with the first entity profile and a secondentity vertex corresponding with the second entity profile. Theassociation between the first entity profile and the second entityprofile may be stored in various forms associating a plurality of entityprofiles, such as an array, a pointer from one of the entity profiles toanother of the entity profiles, an identifier stored in one of theentity profiles that may be used to find another of the entity profile,or the like.

In some embodiments, updating the association between the first entityprofile the second entity profile may be based on a transaction scorebetween the first entity profile and the second profile. The transactionscore may be used as a part of a conditional statement of a norm vertexor may otherwise be associated with the norm vertex. For example, aconditional statement of a rights norm vertex may indicate that a firstentity of a set of norm vertices may trigger a rights norm vertex andcause a second entity to transfer 100 units of a digital asset to thefirst entity, where a transaction score of the rights norm vertex may beor otherwise include the 100 units. In response, some embodiments mayupdate the association between the first entity profile the secondentity profile by increasing an association value by 100 units. In someembodiments, the association between entity profiles may be updated evenif there is no indication that an entity has satisfied or failed aconditional statement. For example, some embodiments may perform regularupdates of an entity graph to update entity graph edges between entityvertices on an entity graph based on parameters of the conditionalstatements of a set of symbolic AI programs, where each entity vertexcorresponds with an entity profile.

In some embodiments, an entity graph may include a plurality of entitygraph edges between a first entity profile and a second entity profileof the entity graph. For example, each entity graph edge of theplurality of entity graph edges may represent a different resource typebeing used in a transaction between the different entities. Someembodiments may update an entity graph edge of the entity graph based ona resource type associated with a transaction score. For example, afirst entity profile may be associated with a second entity profile viaa first entity graph edge and a second entity graph edge, where thefirst entity graph edge represents a computing resource allocation andthe second entity graph edge represents a time allocation. In responseto determining that an event message indicates that the first entity hasallocated 500 GB of storage memory to the second entity, someembodiments may update the entity graph by updating a score associatedwith the first entity graph edge and not updating a score associatedwith the second entity graph edge. Some embodiments may update thenetwork by updating the association representing storage memoryallocation between the first entity and the second entity by adding 500GB to the storage memory.

In some embodiments, the process 2400 may include updating a firstentity score of the entity graph based on the satisfaction or failure ofthe conditional statement, as indicated by the block 2418. As describedabove, an entity score for an entity may represent one of various typesof attributes or behaviors of the entity and may include attributes orbehaviors associated with the satisfaction or failure of norm verticesof a smart contract directed graph. For example, some embodiments mayupdate an entity score of the first entity that represents the number oftimes that the first entity has failed an obligation. Some embodimentsmay include a plurality of entity scores associated with the entityprofile. For example, some embodiments may include an entity profilestoring or otherwise associated with a first entity score and a secondentity score, where the first entity score may indicate a number oftimes that the first entity has failed an obligation norm and a secondentity score may indicate a total amount of times that the first entityhas exercised a rights norm resulting in another entity transferring anamount of digital assets to the first entity.

Some embodiments may obtain a previous entity score stored on adistributed, tamper-evident ledger and update the entity score based onthe previous entity score. For example, some embodiments may obtain aprevious entity score of a first entity equal to a ratio representingthe number of satisfied obligations to the number of total obligations“975/1000.” In response to an event message indicating that the firstentity has satisfied another obligation, some embodiments may update theentity score by adding one to the numerator and denominator of theprevious entity score to result in the ratio “976/1001.”

In some embodiments, the first entity score may be stored in the firstentity profile or otherwise associated with the first entity profile.For example, the first entity score may part of an entity profile storedon a tamper-proof, distributed ledger. In some embodiments, a firstentity score may be encrypted and updating the first entity score mayinclude sending an encryption key in conjunction with or otherwiseassociated with update values, where the update values may be used toupdate the first entity score or otherwise update the first entityprofile. Some embodiments may obtain access to the encryption key or useof the encryption to a specified set of entities. For example, someembodiments may provide the encryption key associated with the firstentity to the first entity itself, entities associated with one or moretransactions with the first entity, a verified set of third-partyentities, or the like. By securing the first entity score based on anencryption key, some embodiments may reduce the risk of unauthorized orotherwise inappropriate changes to an entity score of the first entityprofile.

In some embodiments, operations of the process 2400 may includedetermining whether the entity score satisfies an entity scorethreshold, as indicated by block 2430. In some embodiments, the entityscore threshold may be associated with a predetermined value or becontrollable by a verification entity. Some embodiments may include aplurality of entity score thresholds, where each of the entity scorethresholds may be associated with a specific type of entity score. Forexample, some embodiments may include a first entity score thresholdrepresenting a threshold amount of computing resources allocated over aperiod of time and a second entity score threshold representing athreshold amount of energy consumed by the first entity. If the entityscore satisfies the entity score threshold, operations of the process2400 may proceed to operations described for block 2434. Otherwise,operations of the process 2400 may proceed to operations described forblock 2440.

In some embodiments, operations of the process 2400 may include storinga set of satisfaction values indicating that the first entity satisfiesthe entity score threshold, as indicated by block 2434. In someembodiments, the satisfaction value may be determined and shared withthe first entity profile by a verification entity. For example, averification entity may determine that a first entity satisfies entityscore threshold, indicating that the first entity fulfills a requiredpercentage of obligation norms. In response to this determination, someembodiments may store a satisfaction value in the entity profile of thefirst entity, where the satisfaction value indicates that theverification entity has determined that the entity score of the firstentity satisfies the entity score threshold. Alternatively, or inaddition, the satisfaction value indicating that the first entitysatisfies the entity score threshold may be stored in a storage memoryof the verification entity or in another data storage system.

By storing the satisfaction value indicating that the first entitysatisfies the entity score threshold, other entities may then be allowedto determine that the first entity satisfies the entity score thresholdwithout requiring additional computations that may slow down ondistributed computing platforms. Furthermore, a verification entity mayprovide a satisfaction value indicating that a first entity satisfiesthe entity score threshold. Providing satisfaction values from averification entity may enable some embodiments to protect the privacyof a first entity while still allowing other entities to trust orotherwise predict the behavior of the first entity.

In some embodiments, operations of the process 2400 may includedetermining whether a score access passkey value is obtained, asindicated by block 2440. The score access passkey value may be obtainedby a smart contract management system to determine whether an entityscore associated with an entity profile can be shared with ascore-requesting entity. In some embodiments, the score access passkeyvalue may be obtained as a part of another message sent to an API. Insome embodiments, the score access passkey may include a series ofalphanumeric characters, a set of values, hashed value(s), or the like.In some embodiments, the score access passkey for a satisfaction valueof a first entity may be received from the first entity itself.Alternatively, or in addition, the score access passkey may be obtainedfrom a second entity associated with the first entity via a transactiongraph or an authenticated third party. If a determination is made thatscore access passkey is received, operations of the process 2400 mayproceed to block 2444. Otherwise, operations of the process 2400 may beconsidered as complete.

In some embodiments, operations of the process 2400 may include sendinga set of satisfaction values to the third party, as indicated by block2444. In some embodiments, the set of values may include one or morevalues indicate that the first entity satisfies the entity scorethreshold. Some embodiments may send a message to another entity or anAPI based on a set of satisfaction values indicating that the entityscore satisfies the entity threshold. For example, some embodiments maysend a message indicating that a first entity score of a first entitysatisfies the entity threshold to an application program interface of asecond entity. Furthermore, as discussed above, some embodiments maydetermine additional entities that may be associated with the firstentity based on a path through an entity graph and send the message tothese additional entities as well. Furthermore, some embodiments mayprovide a satisfaction value without any score access passkey beingobtained. For example, some embodiments may provide a first satisfactionvalue to set of entities without obtaining a score access passkeyassociated with the first satisfaction value but require that a scoreaccess passkey be received from an entity before providing the entitywith a second satisfaction value.

As described above, some embodiments may provide scores for entitiesbased on event information without requiring some information that anentity may set as private or otherwise render inaccessible to otherentities. In addition to obtaining a score associated with an entity,some embodiments may determine other information associated with anentity or events caused by entities using one or more queryingoperations. Some embodiments may perform operations, such as thosedescribed further below, to use a hybrid computing environment to queryor process query results with greater efficiency.

Confidential Governance Verification for Graph-Based System

Real-world transactions and other interactions between entities oftenoccur in a framework of governing conditions. This framework ofgoverning conditions may be constructed from a variety of governingdocuments such as internal policies, established protocols, regulations,laws, or the like. These governing conditions may be taken into accountwhen executing a self-executing protocol (e.g., smart contract program)to reduce the risk of significant damage stemming from the violation ofone or more governing conditions specific to one or more of the parties.For example, some regulations may include a rule that requires a firstentity to verify that each other entity the first entity has hadtransactions with be known and not part of a prohibited parties list. Aviolation of a rule in a governing document may result in penalties, ahalt to transactions, or other negative outcomes to the violatingentity. While an entity may already include processes to account forthese types of governing conditions (sometimes known asKnow-Your-Customer processes or KYC processes), these processes may bedifficult to implement or demonstrate the effectiveness of due totechnological limitations and malicious agents. These attempts may befurther hampered by the desired or required anonymity of entities takingpart in digital transactions with respect to each other or the complexnature of certain transactions. For example, some governing conditionsmay correspond to a set of actions that may be allowed individually but,when integrated as a combined set of actions, would be prohibited by thegoverning condition.

Some embodiments may convert or otherwise adapt a governing documentinto a set of governing conditions, each of which may require orrestrict an entity's action(s). For example, a governing condition mayrequire that all entities party to a transaction or type of transactionbe authorized by a verification agent or restrict the execution oftransactions associated with globally prohibited entities. Someembodiments may address these requirements using a cross-program entityidentifier that may be confidential with respect to an entity or set ofentities but mapped to the entity across a domain of smart contractprograms. For example, an entity that is a party to three differentsmart contract programs may be listed under three different entityidentifiers for each smart contract program, but each of the threeentity identifiers may be confidentially mapped to the cross-programentity identifier via a data table, an associative array, or the like.Some embodiments may confirm that the entity satisfies a governingcondition without revealing a cross-program identity of the entity.

While some embodiments may determine that a governing condition isviolated based on the governing condition being satisfied, it should beunderstood that other governing conditions may be considered violatedbased on the governing condition not being satisfied. As discussedfurther below, some embodiments may determine whether a violation iscaused by the satisfaction or failure of a governing condition based ona pre-set default parameter (e.g., not satisfying a governing conditionencoded in a program results in a determination that the governingcondition is violated). Alternatively, or in addition, some embodimentsmay refer to a parameter associated with a respective governingcondition to determine whether the satisfaction or failure of therespective governing condition results in a violation of the respectivegoverning condition.

FIG. 17 shows an example of a computer system usable to determine a setof governing conditions, in accordance with some embodiments. In someembodiments, the computing environment 2700 may include a computingsystem 2710. In some embodiments, the computing system 2710 may includea plurality of computing devices in communication with each other via anetworking system. For example, the computing system 2710 may include aplurality of devices operating a decentralized computing platform usedto execute some or all of the operations described in this disclosure.Alternatively, or in addition, the computing system 2710 may include asingle computing device used to execute some or all of the operationsdescribed in this disclosure.

In some embodiments, the set of computing systems may include a naturallanguage processing (NLP) subsystem 2714. The NLP subsystem 2714 maypart of an application that is executing on a single device or aplurality of devices. For example, the NLP subsystem 2714 may beexecuting on a single device or a subset of the plurality of devices,where training parameters, weights, or other results of the NLPsubsystem 2714 may be distributed to other devices of the plurality ofdevices. The NLP subsystem 2714 may obtain a set of natural languagedocuments 2704 to determine a set of governing conditions. In someembodiments, the NLP subsystem 2714 may include or otherwise access anontology repository 2716 in combination with an entity identifier todetermine a set of governing conditions, as further described below.Alternatively, or in addition, the NLP subsystem 2714 may apply one ormore operations described in provisional patent application 63/034,255(“Semantic Contract Maps,” filed 3 Jun. 2020, herein incorporated byreference) on a set of governing documents to determine a set ofgoverning conditions. For example, some embodiments may includeoperations to apply a set of linear combinations of feature observationsand cross observations across first order and second orders in thefeature space of a governing document to determine a set of governingconditions.

In some embodiments, the computing system 2710 may obtain a set ofcomputer-interpretable smart contract data 2706. Thecomputer-interpretable smart contract data 2706 may include some or allof the data of one or more smart contracts, such as those describedabove. For example, the computer-interpretable smart contract data 2706for a first contract program may include a graph of norm vertices, theircorresponding edges, a list of entities associated with that firstcontract program, a set of program state variables, or the like.Alternatively, or in addition, the computer-interpretable smart contractdata 2706 for the first contract program may include a value(s) obtainedfrom a different type of computer-interpretable document, such as onedescribed in “Smart contract templates: foundations, design landscapeand research directions” by Clack et al. (Clack CD, Bakshi V A, andBraine, arXiv preprint arXiv:1608.00771. 2016 Aug. 2). For example, thecomputer-interpretable smart contract data 2706 may include or obtainvalues from a Ricardian contract implemented in JSON code. The computingsystem 2710 may extract one or more governing conditions from the set ofcomputer-interpretable contract data 2706 and update the set ofentity-applicable governing conditions 2718 by determining whichconditions(s) of a set of governing conditions are applicable to one ormore entities based on their associated cross-program entity identifier.As used in this disclosure, a document that is “computer-interpretable”is encoded in a way such that variable names, variable values, dataobjects, or other elements of a computer program may be parsed from thedocument without requiring the use of advanced processing systems, suchas neural network systems or other machine learning systems.

In some embodiments, the computing system 2710 may use the set ofentity-applicable governing conditions 2718 to perform one or more otheroperations described in this disclosure. For example, in someembodiments, the smart contract program subsystem 2722 may apply the setof set of entity-applicable governing conditions 2718 to a smartcontract program to determine a condition-compliant contract programstate 2740. In some embodiments, the condition-compliant contractprogram state 2740 or data associated with the condition-compliantcontract program state 2740 may be sent to a client device 2750.

FIG. 18 shows a flowchart of operations to update an entity profilebased on whether a set of governing conditions are satisfied, inaccordance with one or more embodiments. In some embodiments, theprocess 2800, like the other processes and functionality describedherein, may be implemented by a system that includes computer codestored on a tangible, non-transitory, machine-readable medium, such thatwhen instructions of the code are executed by one or more processors,the described functionality may be effectuated. Instructions may bedistributed on multiple physical instances of memory, e.g., in differentcomputing devices, or in a single device or a single physical instanceof memory, all consistent with use of the singular term “medium.” Insome embodiments, the operations may be executed in a different orderfrom that described. Some operations may be executed multiple times perinstance of the process's execution, some operations may be omitted,additional operations may be added, some operations may be executedconcurrently and other operations may be executed serially, none ofwhich is to suggest that any other feature described herein is not alsoamenable to variation. Operations of the process 2800 may begin at block2804.

In some embodiments, the process 2800 includes obtaining a set ofdocuments, as indicated by block 2804. Some embodiments may obtain adocument as a Ricardian contract or some other document type that isstructured to be computer-interpretable by a computer system. Forexample, the set of documents may include a Ricardian contract documentstored as a hierarchical YAML file with pre-determined tags indicatingconditions, outcomes, affected entities, affected entity categories,affected actions, affected action types, or the like. Alternatively, orin addition, some embodiments may obtain a document in the form of anatural language document from a user device. For example, someembodiments may obtain a natural language document after a user submitsa natural language document from a web browser to an API of theembodiment. Alternatively, or in addition, some embodiments may obtainthe natural language document by receiving a document source addresssuch as a web address, database key, unique identifier, or the like andthen retrieve a natural language document from the document sourceaddress. For example, some embodiments may receive the web address“www.uspto.gov/asdf” as a document source address and then retrieve thenatural language document by accessing the web address“www.uspto.gov/asdf” and storing a version of the web page.

In some embodiments, the system may use optical character recognition(OCR) methods to convert text for subsequent processing. For example,the system may apply OCR methods to process a rendered image of adocument and detect the presence of one or more words in the renderedimage. As described further below, these words may then be processed todetermine word embeddings or text block scores, which may then be usedto generate or otherwise update a governing condition, an outcome(s)associated with the governing condition, or other data associated with aset of governing conditions.

In some embodiments, the process 2800 may include obtaining thegoverning conditions based on the set of documents, as indicated byblock 2808. The governing conditions may be obtained using a set of NLPoperations, such as those performed by the NLP subsystem 2714. In someembodiments, using the set of NLP operations may include operations suchas routing or stemming the words of the set of documents. Using the setof NLP operations may include encoding words, phrases, sentences, orother bodies of text into vectors, where the functions used to encodethe words or other components of text into vectors may include the useof neural network encoders or decoders. In some embodiments, apre-trained neural network may be used, such as a neural network basedon the BERT encoding system. In some embodiments, an ontology graph maybe used to associate or categorize natural language statements toidentify entities, entity categories, resources, resource types,relationships, thresholds, threshold types, rights, obligations,prohibitions, or the like. In some embodiments, some or all of the setof governing conditions may be directly obtained from acomputer-interpretable document without requiring the use of alearning-based NLP system. Furthermore, as described above, someembodiments may use one or more operations described in patentapplication 63/034,255, which is incorporated by reference, to determinea set of governing conditions from the set of documents. For example,some embodiments may use the probabilistic identification system toidentify a set of governing conditions from a trading regulation writtenas a natural language document.

In some embodiments, a plurality of documents may be analyzed. In someembodiments, the plurality of documents or the set of governingconditions determined from the plurality of documents may be rankedbased on precedence values. A precedence value may be assigned to adocument or its associated governing condition(s) when the document isused to determine the associated governing condition(s). Alternatively,or in addition, a precedence value may be assigned or updated to beassociated with a set of governing conditions after the set of governingconditions are determined. In some embodiments, updating a precedencevalue of a document or governing condition from an initial precedencevalue to a new precedence value may cause a re-determination of ahierarchy of governing conditions. Additionally, some embodiments mayuse the updated precedence value(s) to determine a new set of dominantgoverning conditions, as described further described below.Additionally, some embodiments may update the set of governingconditions when an additional document is obtained. For example, someembodiments may generate a first set of governing conditions based onthree natural language governing documents. After obtaining anadditional natural language governing document, some embodiments mayupdate the first set of governing conditions to include governingconditions determined from the additional document, which may cause oneor more operations below to be performed with respect to the updated setof conditions.

In some embodiments, the precedence value may indicate how governingconditions determined from a first document may relate to othergoverning conditions, such as governing conditions from other documents.For example, the first document may be submitted with a first precedencevalue “3” that is mapped to the precedence category “company policy,”and a second document may be submitted with a second precedence value“5” that is mapped to the precedence category “state law.” Someembodiments may assign “company policy” to governing conditionsdetermined from the first document and assign “state law” to governingconditions determined from the second document. As further discussedbelow, these precedence values may be used to reconcile governingconditions addressing a same subject, where a hierarchy of precedencevalues may be used in cases of conflicting governing conditions. Variousother types of precedence values may be used. For example, a precedencevalue may be assigned as a numeric value selected from a set of integervalues between 1 and 10.

The set of governing conditions may be stored in one or more forms incomputer memory. In some embodiments, a set of governing conditions maybe stored in the form of a directed graph or otherwise associated with adirected graph described in this disclosure. For example, someembodiments may generate a set of arrays representing vertices andedges, where each vertex may be associated with a governing condition.In some embodiments, a vertex may be associated with informationassociated with the governing condition of the vertex, such as anoutcome of satisfying or not satisfying the governing condition.Alternatively, or in addition, the set of governing conditions may bestored as a data table or other database structure, where each record ofthe data table may encode a governing condition or informationassociated with the governing condition, such as a precedence value, arank in a hierarchy of conditions, a list of entities or entitycategories to which the governing condition applies to, or the like.

As discussed further below, the set of governing conditions may beassociated with one or more entities of the smart contract program. Forexample, a first governing condition of the set of governing conditionsmay be encoded as a requirement that any entity of a set of entitycategories must have a minimum amount of a resource. In someembodiments, a first governing condition may be determined to beviolated based on a satisfaction of the first governing condition.Alternatively, some embodiments may determine that a governing conditionis violated based on the governing condition not being satisfied. Someembodiments may determine whether the satisfaction of a governingcondition causes violation or non-violation based on a default setting,a category associated with the governing condition, a condition-specificparameter, or the like. In some embodiments, the violation of the firstgoverning condition may cause a change in program state based on theviolation outcome. For example, in some embodiments, violation of afirst governing condition may cause a program state to be suspended ormay prevent transactions of a certain type from being performed.

In some embodiments, a governing condition may encode a restriction onthe parameters of a transaction between different entities. For example,a first condition of the set of governing conditions may be encoded as arequirement that a first entity provides a minimum amount of resourcesor a maximum amount of resources to a second entity. In someembodiments, a condition of the set of governing conditions may beencoded as a restriction on the type of entities that may interact witheach other or with a community of entities. For example, a firstcondition of the set of governing conditions may be encoded as arequirement that each entity of a smart contract agreement is verifiedby an agent, where the verification by the agent may be performed by awritten or digitally-encoded message associated with each entity.Operations to obtain the governing conditions associated with a specificentity are described further in the descriptions corresponding to FIG.19. Some embodiments may explicitly indicate or otherwise associate aparameter with one or more of the obtained governing conditions toindicate whether the satisfaction or non-satisfaction of the governingcondition results in a violation of the governing condition. Theparameter may be initialized or updated by an explicit value encoded ina computer-interpretable governing, set based on an NLP system decision,or the like.

In some embodiments, the process 2800 may include obtaining across-program entity identifier of an entity, as indicated by block2816. In some embodiments, the cross-program entity identifier(sometimes known as a “global unique identifier” or “GUID”) for anentity may be unique with respect to other entity identifiers in adecentralized computing platform or a domain within the decentralizedcomputing platform. For example, some embodiments may store thecross-program entity identifier “xk132115_xa” in a set of cross-programidentifiers in direct association with a first entity, where no otherentity registered in the decentralized computing platform is directlyassociated with the cross-program entity identifier “xk132115_xa” in theset of cross-program identifiers.

In some embodiments, a mapping or set of mappings may exist between thecross-program entity identifier and a set of program-specific entityidentifiers recorded as participating in a set of self-executingprotocols (e.g., a set of smart contract programs) or transactionsoccurring in the context of the set of self-executing protocols. Forexample, where a first entity identifier of a first contract programexecuting on a decentralized platform and a second entity identifier ofa second contract program may both be associated with the samecross-program entity identifier. In some embodiments, the cross-programentity identifier may be confidential or otherwise not accessible to anunauthorized entity, even if the unauthorized entity is capable ofviewing a program-specific entity identifier mapped to the cross-programentity identifier. For example, each of the entities participating in acontract program may be unable to view any cross-program entityidentifiers other than their own, even if they can view program-specificentity identifiers for the other entities participating in the contractprogram. In some embodiments, the cross-program entity identifier may beencrypted using one or more various encryption algorithms, such as onebased on a DES encryption, AES encryption, RSA encryption, anotherencryption algorithm described in this disclosure, or the like.

In some embodiments, a set of cross-program entity identifiers may bestored in persistent storage of one or more nodes of a decentralizedcomputing platform. For example, the set of cross-program entityidentifiers may be stored in persistent storage of some or all of thecomputing devices of a decentralized computing platform. Alternatively,or in addition, the set of cross-program entity identifiers may bestored on a persistent memory of an on-premises server or a centralizedcloud computing service. Some embodiments may store the cross-programentity identifiers in a database with an associated public entityidentifier or set of public entity identifiers.

In some embodiments, an entity may be assigned to two differentcross-program entity identifiers. For example, a first entity having afirst cross-program entity identifier may acquire a second entity havinga second cross-program entity identifier. After the first entityacquires the second entity, some embodiments may associate the secondcross-program entity identifier to the first entity via a pointer, anassociative array, a shared record in a database, or the like. Asdiscussed further below, some embodiments may re-analyze a governingcondition originally determined to be applicable to the second entity todetermine if the governing condition is applicable to the first entity.Some embodiments may indicate that the second cross-program entityidentifier is deprecated after associating the second cross-programentity identifier to the first cross-program entity identifier.

In some embodiments, the process 2800 may include determining a set ofentity-applicable governing conditions based on the cross-program entityidentifier, as indicated by block 2820. A set of entity-applicablegoverning conditions may be determined by determining which subset ofgoverning conditions from a set of governing conditions apply to anentity based on the entity's corresponding cross-program entityidentifier. In some embodiments, the cross-program entity identifier maybe associated with a set of entity categories usable for determiningwhich governing conditions may be applied to the entity identified bythe cross-program entity identifier. Entity categories may includeentity categories common to a general field of industry, entitycategories shared by multiple smart contract program entities, entitycategories used by entities of a specific smart contract program, orentity categories specific to a single entity, or the like. Exampleentity categories may include terms such as “American Banking Entity,”“Foreign Agent,” “SaaS Provider,” “Computing Resource Provider,” or thelike. Furthermore, as discussed elsewhere, while some governingconditions may be determined to be violated based on the conditions(s)of the governing condition being satisfied, other governing conditionsmay be determined to be violated based on the condition(s) of the othergoverning conditions.

Some embodiments may determine whether a governing condition isapplicable to a cross-program entity identifier based on whether anentity category is listed by the governing condition or listed as asubcategory of a category listed by the governing condition. Someembodiments may determine that a first category is a subcategory of asecond category based on an ontology graph, a data table, a truth table,another symbolic AI data structure, or the like. For example, a firstgoverning condition may list “non-US entity” as an entity category, andan ontology graph may lists the entity category “Canadian Company” asbeing a subset of the category “non-US entity.” Some embodiments maydetermine that a first cross-program entity identifier is associatedwith the entity category “Canadian Company,” and that this entitycategory is a subcategory of the category “non-US entity” based on theontology graph. In response, some embodiments may determine that thefirst governing condition is an entity-applicable category for the firstentity.

In some embodiments, a first governing condition may indicate that anentity has a right to perform an action, and a second governingcondition may indicate that the entity is prohibited from performing theaction. Some embodiments may detect a conflict between a pair ofgoverning conditions based on them being associated with differentcategory labels from a set of mutually exclusive category labels and ashared entity or entity category, a shared indicated action, a sharedindicated resource, or some other similarity between the conditions oroutcomes of the two governing conditions. For example, some embodimentsmay obtain governing conditions associated with one of a set of mutuallyexclusive category labels “rights,” “prohibitions,” and “obligations.”Some embodiments may detect a conflict between two governing conditionsif the first governing condition is labeled with the category label“rights” to indicate that a first entity has a right to accelerate arepayment and the second governing condition is labeled with thecategory label “prohibitions” to indicate that the first entity isprohibited from accelerating the repayment.

Alternatively, or in addition, some embodiments may determine that twogoverning conditions may be combined based on a determination that thetwo governing conditions have the same category label from a set ofmutually exclusive category labels. For example, some embodiments maydetermine that a first and second governing conditions are both labeledwith the category label “prohibition” and indicate, respectively, that afirst entity is prohibited from allocating more than 10 terabytes and100 terabytes of memory from a particular server system. In response,some embodiments may combine the first and second governing conditionsby either adding the prohibited amounts (e.g., prohibiting theallocation of 110 terabytes) or selecting the greater of the prohibitedamounts (e.g., prohibiting the allocation of 100 terabytes). Similaroperations to sum quantities of governing conditions or select a greater(or lesser) quantity may be performed when two governing conditions arelabeled as “rights,” “obligations,” or other category labels from a setof mutually exclusive category labels.

In some embodiments, the process 2800 may include determining ahierarchy of governing conditions based on the set of entity-applicablegoverning conditions, as indicated by block 2824. Some embodiments maydetermine a hierarchy of governing conditions based on precedence valuesassociated with the set of entity-applicable governing conditions. Forexample, a set of precedence values may be encoded by a sequence ofprecedence categories ‘[“branch policy”, “company policy”, “cityregulation,” “state regulation,” “federal regulation”],’ where eachprecedence category is mapped to a precedence value. In someembodiments, the sequence of precedence categories may be mapped to asequence of precedence values such that the next category is mapped to agreater precedence value than the value mapped to the previous category(e.g., “branch policy” is mapped to a lower precedence value than theprecedence value of “company policy). In some embodiments, a greaterprecedence value may correspond to a greater level in a hierarchy ofgoverning conditions, which may result in the governing condition havinga greater hierarchy level acting as an overriding condition. Anoverriding condition may negate or otherwise take precedence over agoverning condition that is detected to conflict with the overridingcondition.

Some embodiments may use a precedence value as a precedence category.For example, the precedence value “1” may be associated with a firstgoverning condition as a precedence category of the governing condition.While the above discloses greater precedence values corresponding tohaving a greater precedence in a hierarchy of governing conditions, someembodiments may instead assign lower precedence values to have a greaterprecedence in a hierarchy of governing conditions. Furthermore, whilethe above discloses precedence values in numbers, other forms ofprecedence values are possible, such as letters, a sequence ofenumerated types, a directed graph encoding category values or categorylabels, or the like.

Some embodiments may use a hierarchy of governing conditions to resolvea detected conflict between a plurality of governing conditions. Forexample, a first governing condition associated with the precedencecategory “company policy” may encode a right of a first entity tomonitor the data traffic of a second entity by setting a viewingauthority of the first entity to the boolean value “True.” A secondgoverning condition associated with the precedence category “state law”may include a prohibition on any entities from monitoring the datatraffic of any other entity. As discussed above, some embodiments maydetermine that the first governing condition and the second governingcondition are in conflict with respect to each other based on sharedentity categories and an encoded action of “permit monitoring.” Someembodiments may resolve conflicts by determining which of the governingconditions takes precedence over the other based on the hierarchy ofgoverning conditions (e.g., based on a determination of which governingcondition has a greater precedence value). For example, some embodimentsmay determine that the precedence category “state law” is mapped to agreater precedence value than the precedence value mapped to thecategory “company policy.” In response, some embodiments may remove thefirst governing condition, set the first governing condition asdeprecated, or otherwise indicate that the first governing condition isenforcing a condition that conflicts with a greater precedence governingcondition.

In some embodiments, a first governing condition and a second governingcondition, or their respective outcomes, may be combined. For example, afirst governing condition may include or otherwise be associated with afirst outcome specifying that a first entity is to be penalized with a500 unit loss if the first entity is detected to have had a transactionwith a prohibited second entity. A second governing conditions of thefirst entity may include or otherwise be associated with a secondoutcome specifying that the first entity is to be penalized with a 1000unit loss if the first entity is detected to have had a transaction withthe prohibited second entity. Some embodiments may consolidate these twooutcomes of governing conditions into a single conditional statementpenalizing the first entity with a 1500 unit loss if the first entity isdetermined to perform the transaction with the prohibited second entity.

In some embodiments, the process 2800 may include initializing a set ofvariables, geolocation parameters, or graph portion templates for usebased on the set of entity-applicable governing conditions, as indicatedby block 2828. Initializing a variable may include determining whetherthe variable is already an existing parameter in a program state ordetermining a set of functions usable to determine the variable fromprogram state. By initializing variables, geo-fences, geolocationparameters, graph portion templates, or other variables used by agoverning condition, some embodiments may provide a significantly richerand enforceable set of governing conditions.

Some embodiments may use a decision tree, decision support system,ontology graph on other data structure to determine whether a set ofvariables is already stored in program data or whether a set offunctions are required to compute the variable from values stored inprogram data. For example, the term “cumulative power allocation” may beassociated with the category “quantitative value” in an ontology graph.Some embodiments may then obtain a governing condition encoding theinstructions, “the first entity must allocate up to 1000 units of powerto the second entity per month.” In response, some embodiments maygenerate a new variable “cumulative power allocation” to keep track ofhow many units of power the second entity consumes for the month, whichmay be used to determine if the governing condition is satisfied.Alternatively, or in addition, some embodiments may determine that avariable encoded in a governing condition is already stored in programdata and, in response, include instructions to use the pre-storedvariable. For example, a governing condition may include instructions touse a pre-stored variable “monthly_CPU_core_use” with an associateddescriptor of “monthly memory CPU core usage.” Some embodiments may thendetermine that a first variable that may be named “monthly_CPU_core_use”or may otherwise indicate a monthly CPU core usage is stored in memoryfor a smart contract program. In response, some embodiments may use thefirst variable when determining whether the governing condition issatisfied. In some embodiments, the set of variables may be a sequenceof variables. For example, a governing condition may include a conditionbased on the detection of data use outside of data use patternscorresponding with video streaming, where data use patternscorresponding with video streaming are associated with bandwidth usesoscillating in a sinusoidal pattern.

Some embodiments may obtain a governing condition that includes a set ofgeolocation parameters. A geolocation parameter may include a set ofglobal positioning system (GPS) coordinates, a geofence defining aphysical boundary, a set of geographic locations, or the like. Forexample, some embodiments may obtain a governing condition encoding arestriction on a geographic location titled “location 1” and determine ageofence based on the value of “location 1.” In some embodiments, a setof geographic coordinates or related values forming a geofence may beencoded into a governing condition. Alternatively, or in addition, someembodiments may refer to a value(s) stored in a geographic informationsystem (GIS) to determine a place or a geofence for the place. Forexample, some embodiments may obtain a governing condition restricting atransaction(s) with entities associated with a region (e.g., a country,a state, a city, a neighborhood, or the like), where the governingcondition includes the region's name. Some embodiments may communicatewith the API of a GIS system such as Google Maps to determine theboundary of the region based on the name. Some embodiments may use theboundary as a geofence to determine if a geographic location associatedwith an entity or transaction associated with the entity falls insidethe geofence.

In some embodiments, a governing condition may encode a graph portiontemplate or otherwise be associated with a graph portion template. Forexample, a governing condition may include a set of vertices and edgesrepresenting vertices and edges of a graph portion template.Alternatively, or in addition, a governing condition may include arecord index identifier pointing to a record in a library of graphportion templates. In some embodiments, the governing condition mayencode a graph portion template that represents a behavior to beexplicitly restricted or allowed. For example, a graph portion templateencoded in a governing condition may include three vertices indicatingthat a set of conditional statements associated with the vertices havebeen satisfied, where the governing condition prohibits the set ofconditional statements from being satisfied. In response, someembodiments may prevent a transaction from causing the satisfaction ofthe set of conditions, generate a GUI warning indicating that thegoverning condition is being violated, generate or store a tagindicating that the governing condition has been violated or is at riskof being violated, or the like.

In some embodiments, a governing condition may be based on valuesdistributed across different programs. For example, some embodiments maydetermine a set of score changes associated with a first entity bydetecting the set of score changes. Additionally, or independently, someembodiments may determine which set of program-specific entityidentifiers are associated with the score changes. Additionally, orindependently, some embodiments may determine the cross-program entityidentifier associated with each of the program-specific entityidentifiers. By determining using the cross-program entity identifier,cross-program entity-applicable conditions may be tested even when theparticipants of smart contract programs are anonymized. Some embodimentsmay determine whether a sum based on score changes satisfies a thresholdvalue. For example, a first and second score change may be detected in afirst and second contract program, where the first and second contractprograms identify participating entities by program-specific entityidentifiers. Some embodiments may determine that each of the scorechanges is associated with the same entity based on associations betweenthe first and second program-specific entity identifiers and across-program entity identifier. Some embodiments may then determinewhether the entity satisfies a governing condition based on the firstand second score changes. For example, some embodiments may determinewhether an entity satisfies a governing condition restricting a maximumor minimum net score change over a period of time (e.g., a maximumamount of financial currency acquired over a one week period, a minimumamount of electrical power provided in a one day period, etc.). Someembodiments may determine a summation of the score changes and comparethe summation to a threshold value to then determine if the governingcondition is satisfied.

In some embodiments, the process 2800 may include performing one or moreoperations described by blocks 2840, 2844, 2854, or 2860 for eachrespective smart contract program of the obtained set of smart contractprograms, as indicated by block 2832.

In some embodiments, the process 2800 may include determining whetherthe set of governing conditions is violated based on a set of events,variables, match with a graph portion template, or data stored inprogram state of a smart contract program as indicated by block 2840. Asdescribed above, a governing condition may include various types ofconditions. In some embodiments, a governing condition may include acondition based on whether a variable satisfies a threshold. Forexample, a first governing condition may include a condition based onwhether a score change associated with an event causes satisfies aminimum score threshold to determine whether the first governingcondition is satisfied. Alternatively, or in addition, a governingcondition may include instructions to determine whether a geographiclocation associated with an entity satisfies a location thresholdrepresented by or otherwise determined from a geolocation parameter. Forexample, a second governing condition may include instructions todetermine whether a geographic location of an entity or a geographiclocation where a transaction is executed is associated with a restrictedlocation to determine whether the second governing condition issatisfied.

In some embodiments, a determination may be made that a governingcondition is violated based on a detected violation occurring in asimulated outcome. For example, some embodiments may obtain an eventindicating that a transaction between a first entity and a second entityof a smart contract program is about to occur based on a confirmationbetween the first entity and the second entity to allow the transactionduring the execution of the smart contract program. The event may besimulated and tested with each of a set of governing conditions todetermine if any of the governing conditions are violated. For example,some embodiments may perform a lookup operation based on a firstcross-program entity identifier associated with the first entity and asecond cross-program entity identifier associated with the second entityto find an entity-applicable governing condition associated with eitherthe first entity or second entity. Some embodiments may then simulate anoutcome based on the program state of the smart contract program and theevent to determine whether the entity-applicable governing condition isviolated by the transaction in the simulated outcome. In response to adetermination that the governing condition is violated by thetransaction in the simulated outcome, some embodiments may take actionas if the governing condition is violated.

In some embodiments, operations of the process 2800 may be performedconcurrently with a smart contract program capable of updating programstate based on a detected event. In some embodiments, the event may beencoded in an event message received by an application executing therespective contract program. For example, a distributed applicationexecuting the respective contract program may receive a first eventmessage at an API, where the first event message indicates an eventcorresponding to a first entity transferring a set of digital assets toa second entity. Some embodiments may obtain an event based on anindication that the event is about to occur, and may simulate theoccurrence of the event to determine whether one or more governingconditions would be violated before the event actually occurs.Alternatively, or in addition, obtaining an event may include simulatingthe occurrence of a possible event. For example, some embodiments mayobtain an event indicating that a first entity will fail to fulfill itsobligations to a second entity based on a simulation result.

In some embodiments, the governing condition may be violated based on aprogram state resulting from an event. For example, a governingcondition may include a requirement that an allocated reserve score fora first entity is greater than 10% of a total transaction amountassociated with the score. After a first event, the total transactionamount may result in the first entity having an allocated reserve scoreless than 10% of a total transaction amount. In response, someembodiments may determine that the first governing condition isviolated.

Some embodiments may include additional operations to look throughprevious events or program states associated with previous events. Forexample, some embodiments may search through some or all of the eventsencoded in the history of a smart contract program to determine if agoverning condition associated with the contract program is violated. Inaddition, or alternatively, some embodiments may search through ahistory of program states of a smart contract program to determine ifany of the governing conditions were violated. While the above describesthe occurrence of an event, some embodiments may look through a historyof previous events previous program states of a smart contract programwithout requiring a new event to have occurred. In response to adetermination that a governing condition was violated, operations of theprocess 2800 may proceed to block 2844. Otherwise, operations of theprocess 2800 may proceed to operations described by block 2860.

In some embodiments, the process 2800 may include performing one or moreoutcomes associated with the violated governing condition, as indicatedby block 2844. In some embodiments, the outcome may be explicitlyencoded in the governing condition. For example, the governing conditionmay include an outcome instructing an application to penalize the firstentity by an amount, restrict the first entity from interacting with anyother entities, send a message to a third-party observer, or the like.Alternatively, or in addition, some embodiments may include instructionsto perform a set of default operations in response to the violation of agoverning condition. For example, some embodiments may send a message toan entity acting as an oversight agent in response to a violation of anygoverning conditions associated with the precedence value “governmentlaw.”

In some embodiments, a governing condition may have been violated in asimulated outcome instead of being violated during an actual executionof the program state. The outcome of a simulated violation may result inthe generation of a warning message that the governing condition may beviolated. Alternatively, or in addition, an outcome of a simulatedgoverning condition violation may include simulated penalties, simulatedconsequent events, or other simulated possible outcomes to be stored ina record of directed graph simulation. Furthermore, in some embodiments,a warning may be sent to an entity based on a score or other value of atransaction meeting a warning threshold associated with a governingcondition. For example, some may first determine a warning thresholdbased on a value included in a governing condition, such as determininga warning threshold of 80% based on a governing condition having athreshold of 100%. Some embodiments may send a warning message to afirst entity based on a determination that a score (e.g., a cumulativeamount of a digital asset being traded, a monthly total of computingresource use, or the like) of a transaction involving the first entitysatisfies the warning threshold of 80%.

Some embodiments may hold a transaction in a pending state in responseto a determination that a governing condition is violated, where actionstaken during the transaction may be reversed while the transaction isheld in the pending state. For example, some embodiments may reverse thetransfer of a digital asset, de-allocate a resource, or otherwise undoan exchange between a set of entities for a transaction while thetransaction is pending. Some embodiments may wait for a threshold periodof time after making a first determination that a set of governingconditions are violated and re-determine whether the set of governingconditions are violated. For example, after determining that a governingcondition requiring that a first entity be authenticated by athird-party agent is not satisfied, resulting in an indicated violationof the governing condition, some embodiments may wait for 10 minutes andthen re-determine whether the first entity is authenticated by thethird-party agent. In response to a determination that the governingcondition is now satisfied, the pending transaction may be allowedproceed, where allowing the pending transaction to proceed may includesetting a variable to indicate that the pending transaction has beenconfirmed or persisting the transaction to a persistent storage deviceof a decentralized computing platform (e.g., via storage in adistributed, tamper-evident ledger).

In some embodiments, a transaction between a set of entities may requireadditional actions before the transaction may be permitted in caseswhere a governing condition is violated by an entity. Some embodimentsmay require verification for a transaction from a third-party entityindicating that a pending transaction is permitted. In some embodiments,the requirement may be encoded as a governing condition or may beencoded as a conditional statement that is part of a smart contractprogram. For example, a first entity may allocate a resource to a secondentity during a pending transaction between the first entity and thesecond entity, where the transaction data of the pending transaction maythen be sent to a third-party entity for validation. Some embodimentsmay then determine whether the transaction is valid based on thecross-program entity identifiers of the first entity, the second entity,and data associated with each entity. In some embodiments, the data mayinclude the first entity having an available amount of funds, the secondentity having a proof of ownership of an asset, or the like. Someembodiments may permit the occurrence of the transaction aftervalidation by the third-party entity. Permitting the occurrence of thetransaction may include indicating that a pending transaction has beenvalidated in a persistent storage, permitting data from a pendingtransaction to be stored in a data table of verified transactions,storing data from the pending transaction as a transaction verified bythe third-party entity in a distributed, tamper-evident ledger, or thelike.

In some embodiments, the process 2800 may include determining whetherany additional contract programs are available for processing, asindicated by block 2854. In some embodiments, a system may determinethat additional smart contract programs are available based on adetermination that a loop used to cycle through each contract program ina list of obtained smart contract programs has not reached a terminationcondition. In response to a determination that additional smart contractprograms are available for processing, the process 2800 may return tothe operations described for block 2832. Otherwise, operations of theprocess 2800 may proceed to the operations described for block 2860.

In some embodiments, the process 2800 may include updating a set ofentity profiles or other program data based on the status(es) of the setof governing conditions, as indicated by block 2860. Some embodimentsmay update a status of a profile for an entity associated with across-program entity identifier to indicate whether the entity hasviolated a governing condition. For example, some embodiments maydetermine that an event detected to have violated a first governingcondition was caused by an action of a first entity. In response, someembodiments may update a first entity profile status that is associatedwith the first entity with an indication that the first entity hasviolated the first governing condition. In some embodiments,non-violation of a condition may cause the updating of a status. Forexample, some embodiments may store an status indicator that the entityhas not violated any of a set of governing conditions.

Some embodiments may generate a profile for an entity in response to adetermination that an existing profile for the entity is not found,where the profile may be referenced by, include, encode, or otherwise beassociated with the entity's cross-program entity identifier. During thegeneration or updating of an entity, the entity may be characterized orotherwise associated with an entity profile storing data about theentity, where the entity profile may be referenced by the cross-programentity identifier. For example, some embodiments may obtain data aboutan entity by determining a cross-program entity identifier using aprogram-specific entity identifier that maps to the cross-program entityidentifier or is otherwise associated with the cross-program entityidentifier. Some embodiments may determine data from a correspondingentity profile using the cross-program entity identifier as an indexvalue. Some embodiments may obtain a document to verify the identity ofan entity. For example, some embodiments may obtain a natural languagedocument that includes identity information for an entity and for averifying agent indicated as capable of confirming the identityinformation.

Some embodiments may use a using an NLP system to store a verifyingagent identifier, a verifying agent address, an entity name, or othervalue associated with a cross-program entity identifier. In someembodiments, the verifying agent address may include an electronicmessage destination or access information, such as a network port, a webaddress, application program interface (API) connection information, orthe like. Some embodiments may then verify the identity of the entity bysending a first message to the verifying agent to the API or otherelectronic message destination indicated by the verifying agent address,where the message may include the entity name or information associatedwith the entity name such as a digital signature, a physical geographiclocation, a biometric reading, or the like. Some embodiments may thenreceive a response message from the verifying agent indicating that theentity name is valid or that the information associated with entity nameis valid. In response, some embodiments may set the first profileassociated with the first cross-program entity identifier as a verifiedprofile.

In some embodiments, updating the set of entity profiles may includeupdating a set of entity profiles of a set of counterparty entity of acondition-failing entity. For example, some embodiments may determinethat a first entity is responsible for failing a governing condition,such as by causing the generation of a graph portion matching a graphportion template indicated as a prohibited graph pattern by a governingcondition. In response, some embodiments may update the entity profileof a counterparty entity or send a notification message to the secondentity. In some embodiments, the second entity may be a designatedmonitoring entity, system administrator, government entity, or the like.Alternatively, or in addition, some embodiments may select the secondentity based on a determination that the second entity has had atransaction with the first entity or that the second entity isassociated with the first entity via an entity list of a smart contractprogram. Some embodiments may update the profile of the second entity orsend a notification message to the second entity indicating that thefirst entity violated a governing condition even if the second entitywas not determined to have violated any governing conditions. Someembodiments may include a governing condition that prohibits an entityfrom having more than a threshold number of transactions with violatingentities. By keeping track of other entities having had transactions orpossible future transactions with the entities determined to haveviolated a governing condition, significant compliance of the smartcontract programs with a set of governing conditions may be increased.

In some embodiments, a cross-program entity identifier stored in anentity profile or otherwise accessible via the entity profile may beencrypted. In some embodiments, the entity profile may be used to verifythat an entity identified by a cross-program entity identifier isverified as meeting a set of governing conditions without otherprogram-specific entity identifiers associated with the entity even ifone program-specific entity identifier is known. For example, a firstentity may send a query to retrieve the profile of a second entity basedon a first program-specific entity. In response, data from the profileof second entity may be provided to the first entity, the data includinga verification that the first entity satisfies or has satisfied each ofa set of governing conditions without disclosing the cross-programentity identifier of the second entity or other program-specific entityidentifiers of the second entity. By providing a means of verifying anentity's ability to satisfy a set of governing conditions withoutrequiring the disclosure of a cross-program entity identifier, someembodiments may increase the security of a decentralized computingplatform when executing smart contract programs or other symbolic AIprograms.

FIG. 19 shows a flowchart of operations to determine a set of governingconditions based on obtained documents, in accordance with one or moreembodiments. In some embodiments, the process 2900 may include obtaininga set of governing documents, as indicated by block 2904. In someembodiments, obtaining the set of governing documents may includeobtaining a natural language document or a computer-interpretabledocument using methods similar to or the same as those described abovefor block 2804.

In some embodiments, the process 2900 may include determining whetherthe set of governing documents is computer-interpretable, as indicatedby block 2910. Some embodiments may determine that the set of contractinformation is computer-interpretable based on a value stored in the setof contract information. For example, the set of contract informationmay include a JSON file including a field and value pair“ROP_system_compatible: True” and, in response, determine that thecontract information is computer-interpretable. Alternatively, or inaddition, some embodiments may analyze the content of a governingdocument to determine whether the content matches one or more knownpatterns categorized as being computer-interpretable. For example, someembodiments may determine that a set of contract information iscomputer-interpretable in response to the text of the set of contractinformation matching a pattern associated with a compatible Ricardiancontract implementation. In response to a determination that thecontract information is computer-interpretable, the process 2900 mayproceed to operations described for block 2930. Otherwise, operations ofthe process 2900 may proceed to block 2940.

In some embodiments, the process 2900 includes encoding text in thegoverning document into a set of word embeddings, as indicated by block2930. Some embodiments may first stem or lemmatize the words of adocument before encoding text in the governing document to determineembeddings. In some embodiments, each word embedding of the set of wordembeddings may include one or more values, such as a set of valuesrepresented as a vector. Some embodiments may use word2vec or a similarcontext-independent embedding model or another neural network-basedembedding model to compute word embeddings. Some embodiments may useother context-independent embedding models (e.g., non-neuralnetwork-based models) such as the Global Vectors for Word Representationmodel (“GloVe”) to determine word embeddings. Alternatively, or inaddition, some embodiments may use context-dependent embedding modelssuch as ELMo, BERT, Context2Vec, or the like to determine wordembeddings. In some embodiments, a system may apply a plurality ofembedding models to determine embeddings.

In some embodiments, the process 2900 may include selecting a set ofsections of the governing document for further processing based onnatural language processing (NLP) parameters, as indicated by block2932. In some embodiments, determining the set of interpretable sectionsmay include detecting text headers and using the text headers topartition and use for the natural language processing subsystem. Someembodiments may detect the presence of a text header (or other textsection delimiter) based on differences in a set of text spacing, set offont styles, set of text sizes, set of text formats, set of listedenumerations, or the like. For example, some embodiments may determinethe presence of a text header based on an increase in font size withrespect to a majority font size of the text of the governing document.Alternatively, or in addition, some embodiments may use a list of terms,data table, an ontology graph, or the like to determine the region oftext to assign to a text section. Some embodiments may use spatialrelationships between text. For example, some embodiments may determinethat a spatial distance between a first section of text and a secondsection of text satisfies a text spatial distance threshold (e.g., bybeing greater than the text spatial distance threshold). In response,some embodiments may assign the words to separate sections of text. Insome embodiments, the NLP parameters may include use weights, biases, anumber of encoder or decoder layers, or the like. In some embodiments, afirst set of NLP parameters may be transferred as part of a set oftransfer learning operations from a first NLP system to a second NLPsystem.

In some embodiments, a section may be selected using an unsupervisedlearning model to possible entities, entity categories, transactions,transaction types, actions. The unsupervised learning model may includelatent Dirichlet allocation (LDA), latent semantic analysis (LSA),probabilistic latent semantic analysis (PLSA), discrete principalcomponent analysis (discrete PCA), or the like. For example, someembodiments may use an PLSA model to determine one or more entitycategories of a section, where the entity categories may be listed as inan ontology graph. In some embodiments, the unsupervised topic modelingmethod may be combined with a supervised topic modeling method. Forexample, the prediction model may use a LDA2vec model, which may includeuse of an LDA model with a trained neural network embedding model. Asfurther described below, once selected, a section may be furtherprocessed to determine a set of governing conditions from the selectedsection. By selecting specific sections, before applying other NLPoperations, some embodiments reduce computing resource use. Furthermore,a governing condition may be mapped back to a selected section, wherethe mapping may be useful for verifying the accuracy of acomputer-determined governing condition based on a comparison with thetext of the selected section.

In some embodiments, the process 2900 may include updating a set ofgoverning conditions based on the selected sections, as indicated byblock 2936. Some embodiments may use an NLP model to determine a set ofgoverning conditions from a selected section of text, where using theNLP model may include using one or more data pre-processing systems,prediction models, or data post-processing systems. In some embodiments,using a natural language processing model may include determining one ormore word embeddings, as described above. In some embodiments, using aprediction model may include using an unsupervised prediction model.Alternatively, or in addition, using a prediction model may includeusing a supervised prediction model. In some embodiments, using aprediction model may include using both one or more supervisedprediction models and one or more unsupervised prediction models.Additionally, some embodiments may apply one or more operationsdescribed in provisional patent application 63/034,255 to determine setof governing conditions. For example, some embodiments apply a tripleextraction operation described in provisional patent application63/034,255 to determine a governing condition.

In some embodiments, determining the governing conditions may includeusing entity categories, resource categories, or other categoriesassociated with an ontology graph. The ontology graph may be used toassociate or categorize natural language statements to identifyentities, entity categories, resources, resource types, relationships,thresholds, threshold types, rights, obligations, prohibitions, or thelike. In some embodiments, the ontology graph may be used to indicatehierarchical relationships between entities based on entity categories.For example, a first ontology graph may include a first ontology vertexlabeled “category A entity” and a second ontology vertex labeled“domestic US entity.” The first ontology graph may include an ontologyedge from the first ontology vertex to the second ontology vertex, wherethe direction of the ontology edge may indicate that an entity listed asa “category A entity” is also a “domestic US entity.

In some embodiments, the ontology graph may be used to indicatehierarchical relationships between entities based on entity categoriesor hierarchical relationships between resources or resource types. Forexample, the NLP subsystem may obtain a natural language phrase, “thedaily bandwidth of silver level entities must be less than 1 gigabyteper second to avoid mandatory data reduction” from a natural languagedocument of a set of documents. In response, the NLP subsystem maydetermine a governing condition or a corresponding outcome of violatingthe governing condition. For example, the NLP subsystem may convert thenatural language phrase into the computer-interpretable governingcondition “IF silver_level AND (daily_bandwidth_allocation <1)” based onentity categories, resource categories, or relationships determined fromthe natural language phrase.

In some embodiments, the process 2900 may include updating a set ofgoverning conditions based on the computer-interpretable governingdocument, as indicated by block 2940. As described above, values, names,and other elements may be parsed from a computer-interpretable governingdocument to generate or otherwise update a set of governing conditions.For example, some embodiments may obtain a JSON document that includesfields for a contract identifier, a first entity identifier, a secondentity identifier, an obligation for the second entity to allocate aresource to the first entity, and a penalty on the second entity forfailure to allocate the resource. Some embodiments may parse the fieldsof the JSON document to generate a set of governing conditions usingidentifiers, values, descriptors, arrays, functions, or other elementsthat are similar or identical to those parsed from the JSON document.

In some embodiments, the process 2900 may include assigning a set ofprecedence values to the set of governing conditions, as indicated byblock 2950. In some embodiments, a precedence value for a governingcondition may be determined based on a tag or categorization of thegoverning condition. For example, a precedence category “state law” maybe assigned to a governing document during an upload of the governingdocument and the precedence value associated with the label “state law”may be assigned to the governing document. Alternatively, or inaddition, some embodiments may use a pre-defined vocabulary, an ontologygraph, or another symbolic AI component to assign a precedence value tothe set of governing conditions. For example, some embodiments mayprovide the title “CFR TITLE 32” to a rules engine of a symbolic AIsystem to determine that governing conditions determined from thegoverning document associated with “CFR TITLE 32” is associated with aprecedence category “USA Federal Regulation” and its correspondingprecedence value “5.” Alternatively, or in addition, some embodimentsmay use a machine-learning system to determine a precedence value. Forexample, some embodiments may use a neural network to analyze the titleand text of a governing document to determine a precedence category“State Law,” which may be mapped to a precedence value of “4” by someembodiments. As described above, the precedence values may be used todetermine a hierarchy of governing conditions or otherwise reconcileconflicting or duplicative governing conditions.

In some embodiments, the process 2900 may include generating a mapbetween a set of cross-program entity identifiers and the set ofgoverning conditions based on entity data associated with thecross-program entity identifiers, as indicated by block 2960. In someembodiments, generating the map between the set of cross-program entityidentifiers and the set of governing conditions may include generating,modifying, or otherwise updating a data table, associative array, orother multi-dimensional data structure to determine the set of governingconditions applicable to each entity. Some embodiments may generate amap between a cross-program entity identifier and a governing conditionby directly associating the cross-program entity identifier to thegoverning condition in a record of a database. Alternatively, someembodiments may generate a map between a cross-program entity identifierand a governing condition via one or more indirect associations. Forexample, some embodiments may generate a map between a cross-programentity identifier and a governing condition by associating aprogram-specific entity identifier of a smart contract program with across-program entity identifier, where the governing condition isassociated with the smart contract program. The map between the set ofcross-program entity identifiers and the set of governing conditions maythen be used to determine a set of entity-applicable governingconditions.

As described above, some embodiments may verify entities or entitytransactions based a cross-program entity identifier. Additionally, someembodiments may perform other verification operations based on multiplevertices of one or more directed graphs, where each respective directedgraph may encode its own respective codified agreement. Some embodimentsmay perform operations, such as those described further below, todecrease computational resource requirements when determining theeffects that one or more events may have on a set of vertices.

Graph-Based Program State Notification

Multi-party self-executing protocols may cause the execution of manytransactions between multiple pairs of entities, where the quantities,resource types, or other parameters of the transaction may be obtainedfrom conditional statements of the self-executing protocol. As aself-executing protocol remains in execution, an entity may be facedwith an increasingly significant number of terms, where the number ofterms may be greater than five, greater than 10, greater than 100, orthe like. These terms may regulate what the entity can do, must do, oris prohibited from doing. By expanding the number of possible actions toconsider in any sequential analysis, some embodiments may increase thecost of computational analysis or predictions based on a program stateof the in-execution self-executing protocol. Additionally, such systemsmay strain the cognitive load on a human representative of an entity,who may often be forced to make decisions based on the numerous termsunder tight time constraints.

Some embodiments may use a self-executing protocol that associatescategories with vertices represented by program state of theself-executing protocol. Some embodiments may aggregate parameters ofactions indicated by these vertices based on the categories. Someembodiments may provide an entity summarized actions that an entity mayperform, is obligated to perform, or is prohibited from performing basedon that these aggregated parameters. Some embodiments may determineaggregated parameters based on subsets of vertices determined to havebeen triggered by an event message, activated by the event message, orotherwise indicated based on predicted paths through a directed graph.

Some embodiments may further determine one or more actions based on aset of private conditional statements associated with the entity. Asfurther discussed in this disclosure, some embodiments may use dataassociated with vertices categorized as obligations, rights,prohibitions, or the like with private conditional statements associatedwith an entity. The resulting values may then be used to cause furtheractions associated with the entity. Alternatively, or in addition, someembodiments may send one or more values of an outcome program statecaused by or otherwise based on an event message to an electronicaddress of a computing device of the entity. A program executing on thecomputing device of the entity may then use a value(s) of the computingdevices as a part of its own internal electronic workflow. Someembodiments may then receive a private output from the computing deviceof the entity and use the private output to update one or more values inprogram state.

By generating aggregated parameters by using properties of a directedgraph, such as categories associated with vertices, some embodiments maysummarize or otherwise reduce the complexity of managing an entity'sprotocol-encoded tasks. These aggregated parameters may reduce multiplevertices representing prohibitions, rights, obligations, or the likeinto a summarized state having a fewer number of conditions. Someembodiments may then base predictions or analysis on this summarizedstate, which may subsequently reduce the computational cost ofgenerating predictions based on the self-executing protocol.Alternatively, or in addition, some embodiments may present a userinterface (UI) displaying values of a summarized state to reduce thecognitive load of interpreting and keeping track of rights, obligations,or prohibitions of an entity.

FIG. 20 depicts a logical and physical architecture diagram usable fordetermining aggregate parameters, in accordance with some embodiments ofthe present techniques. The computing environment 3500 includes apeer-to-peer network 3503 that includes a first node 3504, a second node3505, a set of validator nodes 3506-3508, and a second subdomain ofnodes 3512, as further described below. In some embodiments, one or moreof the nodes 3504-3508 or the second subdomain of nodes 3512 may besimilar to one or more of the peer computing nodes 1202. As discussedelsewhere in this disclosure, the peer-to-peer network 3503 mayimplement a consensus operation between the set of validator nodes3506-3508 to determine the validity of a message being distributedamongst the nodes of the peer-to-peer network 3503. Additionally, someembodiments may select different nodes of the peer-to-peer network 3503to include or remove nodes from the set of validator nodes 3506-3508.

In some embodiments, the peer-to-peer network 3503 may includeadditional nodes, where the nodes of the peer-to-peer network 3503 maybe organized into different subdomains of nodes. In some embodiments,messages or transactions may be validated or stored using a shardingmodel, where each of the subdomains of nodes may validate or store aportion of the messages or transaction taking place in a distributedprogram running on the peer-to-peer network 3503. For example, the nodes3504-3508 may form a first subdomain, where the set of validator nodes3506-3508 may be used in a consensus operation to determine the validityof the event message 3501 and store information on a distributed,tamper-evident ledger stored on the nodes of the peer-to-peer network3503, where versions of the distributed, tamper-evident ledger may bestored on persistent storage of some or all of the nodes. In someembodiments, a second subdomain of nodes 3512 of the peer-to-peernetwork 3503 may validate a different event message or transaction. Asfurther discussed in this disclosure, some embodiments may then performone or more cross-subdomain operations to transfer data across differentsubdomains, such as between one of the nodes of the second subdomain ofnodes 3512 and the validator node 3507 of the first subdomain of nodes.

Various consensus algorithms may be used to determine the validity of amessage or the role of a node. In some embodiments, each of thevalidator nodes may determine that a message or transaction is validbased on validation rules that include determining whether the messageincludes one or more signature values. For example, some embodiments maydetermine whether the event message 3501 is signed with a signaturevalue indicating that the event message is from a registered sensor orother registered information source. Additionally, as further discussedin this disclosure, some embodiments may determine the validity of asystem based on whether the message includes duplicative information, isvalidated by an independent information source, is signed by anobserver, or the like.

The event message 3501 may be received by the first node 3504. In someembodiments, data of the event message 3501 may then be sent from thefirst node 3504 to the second node 3505, where the second node 3505 maybe registered to an entity that is affected by the event message 3501.The data may include the entirety of the event message 3501 or a set ofparameters obtained from the event message 3501. As discussed in thisdisclosure, some embodiments may validate the event message 3501 todetermine whether the event message 3501 satisfies a set of securitycriteria. Some embodiments may use the validator nodes 3506-3508 todetermine the validity of a message. Some embodiments may also use a setof message validation criteria to validate whether an indicated eventmessage is valid, where an event message may satisfy the set of securitycriteria but not satisfy a set of validation criteria. For example, someembodiments may determine that the event message 3501 may be valid basedon a set of security checks, but determine that the event message 3501is not validated based on a set of parameters encoded in the eventmessage 3501 not being supported by any other information sources.

Some embodiments may begin operations to update program state based onthe event message 3501. For example, some embodiments may update adirected graph 3520 encoded in a self-executing protocol based on theevent message 3501. As further discussed in this disclosure, someembodiments may determine subsets of vertices and associated entitiesbased on the event message and the vertices that it triggers oractivates. The event message 3501 and the subsets of vertices selectedfrom the directed graph 3520 may be used in conjunction with a set ofprivate conditional statements 3530 of an entity to determine tasks forthe entity to perform. Some embodiments may send one or more messagesbased on the resulting directed graph 3520, set of parameters encoded inthe event message 3501, and set of private conditional statements 3532 aprivate computer system 3540 controlled by or otherwise associated withthe entity. In some embodiments, the private computer system 3540 maysend, your one or more APIs, values to one or more nodes of thepeer-to-peer network 3503 two initiate, permit, modify, prevent, orotherwise update a transaction between the first entity and anotherentity.

While the above discloses the use of validator nodes, some embodimentsmay validate messages or transactions without separating thefunctionality of validator nodes from non-validator nodes. For example,some embodiments may use a peer-to-peer network of nodes such that eachnode of the network validates a message or transaction. Alternatively,or in addition, some embodiments may validate a message or transactionof a program operating on a centralized computing device or centralizedplatform.

FIG. 21 is a flowchart of a process to determine aggregated parameters,in accordance with some embodiments of the present techniques. In someembodiments, the process 3600 may include obtaining a program state of aself-executing protocol, as indicated by block 3602. In someembodiments, obtaining a program state may include obtaining a programstate from a still-in-execution program. For example, a firstapplication may be executed over a peer-to-peer network of nodes, andone or more nodes of the peer-to-peer network may store program statefor the application. Some embodiments may download a local version ofthe program state for use when performing one or more operationsdisclosed in this disclosure. Alternatively, or in addition, someembodiments may obtain a program state during a simulation of a program,where the simulation may simulate some or all of the functions oroperations of the program.

In some embodiments, the process 3600 may include receiving a message,as indicated by block 3604. An event message may be one of various typesof messages that changes a program state, and may include a messageindicating the occurrence of a transaction, a message provided by anobserver node, a message provided by a sensor, or the like. In someembodiments, the event message may be received at an API that causes oneor more conditional statements of a set of vertices to trigger or becomeactive. In some embodiments, the event message may be a web message sentover the Internet. The message may be formatted in a pre-determined wayor may be sent in natural language text form. In some embodiments, theevent message may include a set of parameters such as what entity sent amessage, what set of entities are a subject of the message, specificconditional statements or vertices affected by the message, or the like.

Some embodiments may parse the received event message or otherwiseobtain a set of parameters of the event message. For example, a firstevent message may include the hash map ‘[subj1: “Ent1”; action:“allocate”; units: “50”, subj2: “Ent2”; type:“obligation”].” Someembodiments may extract the key-value pairs of the hash map and obtainthe first entity name “Ent1,” the second entity name “Ent2,” the action“allocate,” and the category label “obligation.” In some embodiments,the set of parameters obtained from the first event message may indicatethat the entity “Ent1” has an obligation to allocate 50 units to theentity “Ent2.” Various other operations may be used to obtain a set ofparameters of an event message. For example, some embodiments may useone or more NLP operations to determine a set of parameters from anevent message. Some embodiments may determine the validity of themessage via one or more operations being performed at the node receivingthe event message, using one or more operations described further below.Alternatively, or in addition, some embodiments may determine thevalidity of the event message using a set of validator nodes.

In some embodiments, an entity may be determined to be affected by anevent message that is first received by a first node, where the firstnode is not controlled by or otherwise registered to the first entity.Some embodiments may then determine a path through the networkconnecting the first node to a second node, where the second node iscontrolled or otherwise registered to the entity. If an event message isreceived at a first node, some embodiments may send data of the eventmessage from the first node to the second node.

Some embodiments may determine the network path by performing a breadthfirst search (BFS) or depth first search (DFS) operation through a graphrepresenting a peer-to-peer network of nodes. For example, someembodiments may use an DFS algorithm to determine a shortest path from amessage-receiving node and a destination node by exploring each nodedirectly connected to the message-receiving node (the first layer ofnodes), and then iteratively exploring each node connected to the nextlayer of the message-receiving node until the destination node isselected. In some embodiments, use of the BFS algorithm may generate anetwork path that includes a link from the message-receiving node to anintermediate node and a second link from the intermediate node to thedestination node. As discussed further below, some embodiments mayreduce the amount of time that a node receives a message affecting thenode by using a network path determined using one or more operationsdescribed above. Some embodiments may determine a path through thepeer-to-peer network of nodes to minimize or otherwise reduce the numberof nodes that the event message may visit before arriving at adestination node associated with an entity affected by an event message.

In some embodiments, the process 3600 may include determining whetherthe event message is valid, as indicated by block 3612. Some embodimentsmay determine whether a message is valid by performing operations at amessage-receiving node, a set of validator nodes, or other nodes of apeer-to-peer network. Alternatively, some embodiments may determinewhether the event message is valid by performing operations on acentralized computing platform. Determining that a message is valid mayinclude determining that a set of validation criteria are satisfied. Theset of validation criteria may include a criterion that the messageincludes or is otherwise associated with one or more signature keysprovided by a registered entity. In some embodiments, the set ofvalidation criteria may include a criterion that the message beconfirmed by at least two separate entities.

Some embodiments may implement a consensus protocol to determine thevalidity of a message. For example, after receiving a message at a firstnode of a node network, some embodiments may send the message to aplurality of validator nodes of the node network. to determine if themessage satisfies the set of validation criteria. Alternatively, someembodiments may send the message to every node of the node network forvalidation, where each node of the node network determine the validityof the message using a consensus protocol. Some embodiments maydetermine that a message is valid if a majority of the nodes used todetermine the validity of the message agree that the message is valid.

The set of validator nodes may include any number of nodes, but maypreferably include more than three, more than ten, or more than 50validator nodes to increase validation confidence. Some embodiments mayconcurrently send the event message to an entity listed as affected bythe event message or otherwise determined as being affected by the eventmessage before the set of validator nodes arrive at a consensus on thevalidity of the event message. By sending the event message from thereceiving node to the affected node before the event message isdetermined to be valid, some embodiments may allow operations based onthe event message to begin in cases where validation operations may bedelayed. Some embodiments may determine that a message is valid inresponse to a determination that a hash key or other value indicatingthat a security value is satisfied. For example, some embodiments maydetermine whether a message includes a required security key based onwhether each node of a set of validator nodes form a consensus that themessage includes the required security key.

Some embodiments may include determine that an event message is validbased on additional validation criteria. The additional validationcriteria may be based a set of parameters obtained from the eventmessage. For example, some embodiments may use one or more criteria todetermine whether a received message is a duplicate event message. someembodiments may distribute an issue notification indicating that thereceived event is a duplicate of the previously-received event. Aduplicate event message may include values that are similar to otherevent messages or different from other event messages. Some embodimentsmay determine whether a timestamp or other indication of time associatedwith an event message satisfies a duration threshold between two eventmessages to determine the validity of an event message.

In some embodiments, a duplicate event message of a first event messagedoes not have to be identical to the first event message. For example, afirst event message may include the value “Ent 1 send 30 to Ent 2 at00:01 received 20501212 at node33,” indicating that entity “Ent1”transferred 30 units to entity “Ent2” at 00:01, where the message wasreceived at the node “node33.” A second event message may include thevalue “Ent 1 send 30 to Ent 2 at 00:01 received 20501212 at node34” toindicate that entity “Ent2” transferred 30 units to entity “Ent2” at00:01, where the message was received at node “node34.” In response toreceiving the second message, some embodiments may parse the messageinto parameters, such as the entity names “Ent1” and “Ent2,” thetransaction name “transfer,” and the score “30.” In response to a matchin these parameters between the first message and the second message,some embodiments may determine that the second message is a duplicateevent message with respect to the first event message. Alternatively, orin addition, some embodiments may use a validation criterion thatdetermines that a first message is valid only after receiving a secondmessage duplicating one or more parameters of the first event message.For example, some embodiments may determine that a first event messagecomprising a first entity identifier and a transaction score is validbased on a determination that a second event message received after thefirst event message also includes the first entity identifier and thetransaction score.

If a determination is made that an event message is valid, operations ofthe process 3600 may proceed to operations described for block 3616.Otherwise, operations of the process 3600 may proceed to operationsdescribed for block 3620.

In some embodiments, the process 3600 may include distributing avalidation message to nodes of the node network, as indicated by block3616. The validation message may indicate that the event messageincludes valid information and that operations based on a set ofparameters obtained from the event message may be used. For example, thevalidation message may include a message encoding an identifier of anevent message and a boolean value to indicate that the message hassatisfied one or more validation criteria, such as the validationcriteria discussed above. In some embodiments, the distribution of thevalidation message may be performed as a part of an implementation of aconsensus protocol.

In some embodiments, the distribution of the validation message maycause some embodiments to store the validation message on atamper-evident, distributed ledger encoding records in a directedacyclic graph of cryptographic hash pointers or other distributedstorage of a node network. As discussed elsewhere in this disclosure,versions of the tamper-evident, distributed ledger may be stored acrossmultiple nodes of a peer-to-peer network (e.g., in persistent storagedevices of multiple nodes). For example, during or after distribution ofa validation message, some embodiments may update a set of arrays of atamper-evident, distributed ledger to include an identifier of themessage and a boolean value to indicate that the message is validated.The tamper-evident, distributed ledger may include an array of previousvalues, such as identifiers of previous messages, previous indicationsof validation or invalidation, or the like.

As discussed elsewhere in this disclosure, values stored on atamper-evident, distributed ledger may be stored in sharded databasearchitecture or otherwise arranged such that different nodes have accessto different values. For example, a first stored value of atamper-evident, distributed ledger may be accessible to a first entitythat is permitted to view the first stored value and may not beaccessible to a second entity that is not permitted to view the firststored value. Some embodiments may use a sharding architecture to form aconsensus on the validity of a value or storing the value, where suchsharding techniques may include one or more of those described by Wanget al. (Wang, G., Shi, Z. J., Nixon, M. and Han, S., 2019, October. Sok:Sharding on blockchain. In Proceedings of the 1st ACM Conference onAdvances in Financial Technologies (pp. 41-61)), which is herebyincorporated by reference. For example, some embodiments may determinethe validity of a message using a byzantine fault-tolerant (BFT)consensus protocol, where implementing a BFT protocol may includeoperations to divide a tamper-evident, distributed ledger intopartitions, each partition stored into by a subset of nodes of apeer-to-peer network of nodes. By implementing a sharding technique,some embodiments may increase the scalability of a distributed computingplatform used to perform one or more operations the process 3600.Additionally, some embodiments may skip distributing the validationmessage if the operations of the process 3600 are being performed by asingle computing device.

In some embodiments, the process 3600 may include distributing an issuenotification to nodes of node network, as indicated by block 3620. Asdiscussed above, some embodiments may determine that one or moreparameters of an event message does not satisfy a set of validationcriteria. Some embodiments may provide a corresponding issuenotification based on the set of validation criteria not satisfied bythe event message, where the issue notification may indicate issues suchas the event message providing duplicative information, the eventmessage being provided by an untrusted entity, or the like. For example,some embodiments may determine that a validation criterion is notsatisfied by an event message based on the event message indicating theoccurrence of a transaction already stored in a record as havingoccurred. In response, some embodiments may send an issue notificationindicating the message is a duplicate message.

In some embodiments, one or more types of issue notifications may causean event message to be labeled as invalid. After a determination is madethat an event message is not valid, some embodiments may prevent one ormore operations from being performed based on the invalidated eventmessage. For example, after a determination is made that an eventmessage is invalid, some embodiments may prevent the event message frombeing used to select subsets of vertices as disclosed for block 3630below. Alternatively, or in addition, some embodiments may label one ormore results determined using operations based on the event message asresults that should be deleted, ignored, or otherwise not used forfurther operations. For example, some embodiments may have initiallyreceived a first event message at a node used to execute aself-executing protocol. In response to receiving the first eventmessage, some embodiments may then determine a local instance of anoutcome program state based on the first event message, as furtherdiscussed below. Some embodiments may then determine that the firstevent message is invalid at a later time or receive a message indicatingthat the first event message is invalid at a later time. In response,some embodiments may prevent the local instance of the program statefrom be stored on a distributed, tamper-evident ledger or may otherwiseprevent values of the locally updated instance from being stored in aset of records of values from previous versions of program state.

In some embodiments, the process 3600 may include selecting a firstsubset of vertices triggered by the event message, as indicated by block3630. As discussed in this disclosure, various operations may beperformed determine whether an event message triggers vertices of adirected graph stored in program state, where each respective vertex ofthe vertices may be associated with a respective conditional statement.Some embodiments may determine that a respective vertex is triggered bythe event message based on an event message satisfying one or moreconditions of a respective conditional statement associated with therespective vertex. For example, an event message parameter may include asensor value, and a conditional statement associated with a vertex maybe satisfied if the sensor value exceeds a sensor threshold of theconditional statement. In some cases, satisfaction of the conditionalstatement may cause some embodiments to update a vertex status of theassociated vertex to a “satisfied” state or other state indicatingsatisfaction of the conditional statement. Alternatively, or inaddition, some embodiments may select a vertex based on the vertex beingupdated to a failed state based on an event message. For example, anevent message parameter may include an indication of a quantitativescore of an entity falling below a threshold of a conditional statementassociated with a vertex. In response, some embodiments may determinethat the vertex is failed and include the vertex in the first selectedsubset of vertices.

Some embodiments may determine that a vertex is triggered in response toan event message even if the event message does not include any mentionof a resource amount or resource type of a conditional statement. Forexample, an event message may indicate that a time threshold issatisfied and, in response, some embodiments may determine that a timethreshold associated with the conditional statement of a vertex issatisfied and, consequently, set a vertex status of the vertex as“failed.”

In some embodiments, the process 3600 may include selecting a secondsubset of vertices based on the first subset of vertices, as indicatedby block 3634. the second subset of vertices may be selected based on aset of directed edges associated with the first subset of vertices orotherwise based on a connection with the first subset of vertices. Insome embodiments, the second subset of vertices may include verticesthat were previously inactive or would otherwise not have caused aneffect even if one or more of their corresponding conditional statementswere satisfied. Additionally, the second subset of vertices may includefuture event-activated vertices.

In some embodiments, the second subset of vertices may include ananticipated set of vertices and associated likelihood parametersassociated with the additional set of vertices. In some embodiments,each of the anticipated set of vertices may be connected to an activevertex via one or more directed edges of a directed graph encoded inprogram state. For example, some embodiments may activate a first vertexin response to receiving an event message and select the first vertexfor inclusion in the second subset of vertices. Some embodiments maythen select a second vertex based on a directed edge associating thesecond vertex with the first vertex. Some embodiments may also determineor otherwise obtain a likelihood score indicating the likelihood of thesecond vertex being activated, where the likelihood score may bedetermined using a set of historical data or otherwise predicted using astatistical model or machine learning model.

In some embodiments, the process 3600 may include selecting an entitybased on the first or second subset of vertices, as indicated by block3633. As further discussed in this disclosure, some embodiments mayselect entities to determine what set of private conditional statementsto obtain, what address to send a UI, or the like. Some embodiments mayselect an entity based on an entity role or other entity categoryassociated with the entity. For example, an outcome of a triggeredvertex may include instructions to notify all entities having thecategory “bidder” that a score associated with a digital asset has beenupdated to a new value. In response, some embodiments may select anentity based on the entity having the entity role “bidder.” An entityrole may be shared amongst multiple entities. For example, a first andsecond entity may both have the entity role “subscriber” and the entityrole “publisher.” In some embodiments, the entity role may indicate afunction played by the entity in a self-executing protocol. For example,a first entity may be labeled as an “allocator,” which may indicate thatthe first entity has permission to allocate one or more resources toanother entity of the self-executing protocol. Some embodiments may useentity roles to determine permissions to perform certain operations oraccess certain information.

Some embodiments may determine that an entity has been assigned a newentity role and, in response, send update messages to an addressassociated with the entity based on vertices being associated with thenew entity role. For example, a vertex of a self-executing protocol maybe associated with the entity role “outstanding allocators” and a firstentity may have originally not been associated with this entity role. Ifthe first entity is later assigned or otherwise associated with theentity role “outstanding allocators” at a later time, some embodimentsmay include the first entity in a selected subset of entities that sharethe “outstanding allocators” entity role and determine one or moreaggregated parameters for the first entity. Alternatively, or inaddition, some embodiments may have the entity pre-selected based on oneor more operations of the process 3600 being initiated or caused by anaccessing entity, where the accessing entity may act as a selectedentity.

In some embodiments, the process 3600 may include determining whether anoutcome state caused by the event message satisfying a set of privateconditional statements, as indicated by block 3636. In some embodiments,the outcome state may include values directly updated by an eventmessage, vertex statuses associated with vertices of a directed graph,or the like. For example, an outcome state of a first program statecaused by an event message may include the program state after a firstvariable of the program state representing a vertex status is updated to“satisfied” in response to the event message satisfying the conditionalstatement of the vertex and after a second variable of the program staterepresenting a sensor reading is updated by the event message.

In some embodiments, an entity participating in a self-executingprotocol may be associated with a set of private conditional statements.The set of private conditional statements may be hidden from orotherwise not viewable by one or more other entities of theself-executing protocol. For example, some embodiments may, afterreceiving an event message, change an outcome state based on a firstsubset of vertices triggered by the event message. One or more values ofthe outcome state may be used to determine whether a set of privateconditional statements are satisfied, such as determine whether thefirst entity has allocated an amount of a computing resource to thesecond entity. In response to satisfying a respective privateconditional statement, some embodiments may perform one or morerespective outcome actions of satisfying the respective privateconditional statement.

In some embodiments, results based on evaluations of the set of privateconditional statements with outcome states may be used as a part of anentity's internal workflow. An entity's internal workflow may includevarious operations that may integrate or incorporate outputs of aself-executing program or associated computer programs. As discussedabove, some embodiments may use a set of private conditional statementsthat causes a set of messages to be sent to one or more addresses inresponse to an outcome program state satisfying the set of privateconditional statements. It should be understood that, while someembodiments may send a message or perform other operations in responseto a private conditional statement being satisfied, other embodimentsmay send the message or perform other operations in response to anoutcome state not satisfying a set of private conditional statements.

Alternatively, or in addition, some embodiments may send a message orperform other operations based on other operations directly associatedwith an entity. For example, some embodiments may include operations tocompute a score representing the amount of allocated resources beingpublicly used after receiving each event message and send the score toan address of the entity. The score or other results of these operationsmay then be used by the entity to update one or more internal values orto use as input(s) for other workflow operations.

Some embodiments may use architecture to prevent an outcome transactionor the execution of another operation by the self-executing protocolfrom occurring without a confirmation key or other input value that isrequested by a confirmation request. For example, some embodiments maydetermine that an outcome program state indicating that a first entityis obligated to allocate an amount to a second entity satisfies aprivate conditional statement of the first entity. In response, someembodiments may send a first and second confirmation request to a firstand second address, respectively. In some embodiments, the first andsecond address may be registered to a first and second representative ofthe first entity, respectively. Some embodiments may then preventexecution of a transaction transferring the amount from the first entityto the second entity until a first confirmation key from the firstaddress and a second confirmation key from the second address isreceived. Some embodiments may implement operations to requestconfirmation keys from multiple addresses to increase security during atransaction. Additionally, some embodiments may store one or more of theconfirmation keys in in a distributed, tamper-evident ledger as a partof or in association with data recording evidence of the transaction.

In some embodiments, the process 3600 may include filtering the subsetsof vertices determined above based on a set of shared categories, asindicated by block 3638. In some embodiments, set of shared categoriesmay be a shared category of a set of mutually-exclusive categories. Forexample, some embodiments may collect a set of vertices based on each ofthe set of vertices being associated with the category label “right” ofthe set of mutually exclusive categories “[“right”, “obligation”,“prohibition”]”. In some embodiments, each respective category label ofthe set of mutually exclusive categories may be used to select multiplesubsets of vertices, where each respective subset of vertices share acategory label.

In some embodiments, a vertex sharing a category selected from amutually-exclusive set of categories may share one or more properties,associated behaviors, or the like. For example, a first category label,such as the category labeled with the title “obligation,” may beselected from a set of mutually-exclusive categories labeled [“rights”,“obligations”, “prohibitions”]. Each respective vertex of the verticeslabeled with the category label “obligation” may include a timethreshold associated with another conditional statement. Failing tosatisfy the conditional statement by the time threshold may result inthe vertex status of the respective vertex being updated to indicate afailed state. It should be understood that the specific title“obligation” may be changed to various other terms, such as“requirement,” “cat1,” or the like, and that a change in the title ofthe category does not change operations based on the category. Asfurther discussed below, determining aggregated parameters based onvertices categorized as “obligations” may include determining a netamount based on the each of the parameters associated with each of theset of active vertices labeled as “obligations.”

In some embodiments, a second category selected from the set ofmutually-exclusive categories may be labeled “prohibition” and may beassociated with a conditional statement that, if satisfied, may cause avertex associated with the conditional statement to be labeled as afailed vertex. For example, a vertex labeled with the second categorymay initially be active and, be changed to a status indicating failurein response to a event message satisfying the conditional statement ofthe vertex. In many cases, as further discussed below, prohibitionsassociated with different prohibition vertices from a sameself-executing protocol or multiple sub-executing protocols may becombined to simplify prediction models, visual interfaces, or otheroperations. As further discussed below, determining aggregatedparameters based on rights may include determining a net amount based onthe each of the parameters associated with each of the set of activevertices labeled as “prohibitions.”

In some embodiments, a third category selected from the set ofmutually-exclusive categories may be labeled “right” may be associatedwith a conditional statement that requires an explicit request by anentity to trigger. For example, a vertex labeled with the third categorymay initially be in an active state and require an entity to send amessage triggering the vertex, which may then activate one or more newvertices. As further discussed below, determining aggregated parametersbased on rights may include determining a net amount based on the eachof the parameters associated with each of the set of active verticeslabeled as “right.”

In some embodiments, the process 3600 may include determining a set ofaggregated parameters based on a subset of vertices sharing a category,as indicated by block 3640. The set of aggregated parameters may includea quantitative or categorical value determined from combining, via oneor more functions, values used by a set of conditional statementsassociated with a subset of vertices. For example, some embodiments maydetermine an aggregated parameter value based on values associated withthe second subset of vertices described above, where each of the secondsubset of vertices used may have a shared category label. For example,each of the vertices associated with a value used to determine anaggregated parameter value may share the category label “right” from aset of mutually-exclusive category labels “[right, obligation,prohibition]”. Some embodiments may then store an aggregated parameterin persistent storage, where it may be retrieved for later use or storedon a distributed, tamper-evident ledger.

Some embodiments may determine a sum as an aggregated parameter, wherethe embodiments may use threshold values encoded in a set of conditionalstatements as inputs when determining the aggregated parameter. Forexample, a subset of vertices labeled with the category “obligation” mayhave a corresponding subset of conditional statements, where therespective thresholds of the conditional statements may be equal to thevalues “100,” “105,” and “201.” Some embodiments may determine that thesum of the values, “406” as the aggregated parameter, where theaggregated parameter may represent a total amount to be owed, allocated,or otherwise associated with a resource type involved in an obligation.

Some embodiments may use weights assigned to vertices of the secondsubset of vertices when determining an aggregated parameter. Forexample, as discussed above, the second subset of vertices may includenon-active vertices that have not been triggered, each of which areassociated with a weight indicating a probability of occurrence. Someembodiments may compute an expected value based on the weight and usethe expected value as a part of a prediction model or for display in aUI. For example, some embodiments may determine that, after theactivation of a first vertex by an event message, the first vertex mayresult in two possible outcomes based on a satisfaction or failure of aconditional statement of the first statement, where each of the twopossible outcomes are associated with a respective first and secondweight. Some embodiments may then multiply the amount received in thefirst outcome by the first weight and multiply the amount received inthe second outcome by the second weight to determine a net anticipatedamount. Some embodiments may then provide the net anticipated amount asan aggregated parameter for display in a UI or as an input for otheroperations.

Some embodiments may execute or simulate the execution of one or morevertex interactions when determining an aggregated parameter. Forexample, one or more vertices of a set of active vertices may cancel orotherwise update another vertex of the set of active vertices, wheresuch updates may be considered when determining an aggregated parameter.Some embodiments may simulate the triggering of one or more of theactivated vertices to determine a maximum or minimum aggregate amountand use the maximum or minimum aggregate amount as an aggregatedparameter. For example, some embodiments may detect the presence ofactive vertices and determine, via relationships encoded in the directededges of the directed graph of the self-executing protocol, that thetriggering of a first obligation vertex may cancel a second obligationvertex and that the triggering of the second obligation vertex maycancel the first obligation vertex. The first vertex may be associatedwith a first conditional statement that requires the allocation of afirst amount from a first entity to a second entity. The second vertexmay be associated with a second conditional statement that requires theallocation of a second amount from the first entity and the secondentity. Some embodiments may then determine a minimum amount to beobligated based on the cancellation interaction between the first vertexand the second vertex and use the minimum amount as an aggregatedparameter, where the aggregated parameter may then be displayed in a UIin a region associated with obligations (e.g., in a region visuallytitled “obligations,” “required tasks,” or the like).

In some embodiments, the process 3600 may include providing a UI basedon the set of aggregated parameters, as indicated by block 3650. The setof aggregated parameters to be used in a UI to display aggregatedparameters based on vertex categories, and may include a current amountowed, a current amount to be allocated within a time interval, an amountanticipated to be received within a time interval, or the like. In someembodiments, a plurality of vertices may be associated with each of theupper values, where a visualization of the plurality of verticesassociated with the output may be changed to emphasize the relationshipbetween the plurality of vertices and the associated up. For example,some embodiments may provide a UI having a first UI element thatdisplays a sum of the obligated amounts associated with a plurality ofvertices.

In some embodiments, a UI may also include a visualization of thedirected graph, where clicking on the sum of obligated amounts willcause the visualization to highlight the associative plurality ofvertices shown in the directed graph. For example, some embodiments mayvisually indicate a subset of vertices that were activated by an eventmessage, where the subset of vertices is shown to be different fromother vertices being displayed in the UI. Various methods may be used tovisually distinguish the subset of vertices. Visually distinguishing avertex from other vertices may include changing a color of the vertex,changing a size of the vertex, or animating the vertex in a differentway with respect to the other vertices of the directed graph.Alternatively, or in addition, the UI provided by some embodiments maycause one or more additional operations to be performed in response toan interaction with a UI element of the UI. In some embodiments, theadditional operations may include sending messages or otherwise causingadditional interactions between a local machine executing and displayingthe UI and a self-executing protocol executing across a distributed,peer-to-peer network.

FIG. 22 depicts a user interface that displays aggregated parameters, inaccordance with some embodiments of the present techniques. FIG. 22depicts a UI that displays a result based on aggregated parameters, inaccordance with some embodiments of the present techniques. The UI 3700may include UI elements generated based on one or more aggregatedparameters determined using one or more operations described in theprocess 3600. The first UI element 3704 may be based on a firstaggregated parameter having the value “1000,” where the aggregatedparameter indicates a maximum amount of resource units that must betransferred to the entity “Ent2.” Some embodiments may have selectedvalue “1000” from three different parameters [200, 500, 1000], whereeach parameter may represent a threshold of a conditional statement of adifferent prohibition vertex. Additionally, the first UI element 3704may include an indicator indicating that the use of a resource tofulfill a non-obligated activity is prohibited based on a privateconditional statement, where the indicator may be the text “[P]” thatprecedes the phrase “Use Resource To Fulfill Non-Obligated Activity.”

The second UI element 3708 may include the aggregated parameter havingthe value “900,” where the aggregated parameter may be determined from aplurality of vertices categorized as “rights.” In some embodiments,interaction with the second UI element 3708 may cause the display of theplurality of vertices. For example, a user may interact with the secondUI element 3708 by clicking on or tapping on the text, “Acceleratetransfer of 900 resources from Ent4.” In response, the UI 3700 may thendisplay a new box indicating two vertices or their associatedconditional statements, where each of the two indicated respectivevertices is associated with an acceleration of an amount of resourcesfrom the entity “Ent4,” and where the amounts sum to the quantity “900.”In some embodiments, interactions with this new box or another UIelement may then cause a message to be sent to a self-executing protocolthat trigger one or more of the indicated respective vertices. Forexample, some embodiments may click on a button in the UI that, whenpressed, sends a message to a self-executing protocol and triggers arights vertex to accelerate the transfer of an amount from the entity“Ent4.”

As discussed above, some embodiments may determine an aggregatedparameter based on vertex relationships encoded in a set of directededges or other associations between vertices. For example, someembodiments may have determined the value “900” from a first parameter“300,” a second parameter “500,” and a third parameter “600,” where eachparameter may represent a quantity that may be requested from the entity“Ent4.” A first conditional statement may use the first parameter “300,”and may be associated with a vertex that is independent of any othervertex. The second parameter “500” and the third parameter “600” may beused by a second and third conditional statement, respectively, wherethe second conditional statement is associated with a second vertex, andwhere the third conditional statement is associated with a third vertex.Some embodiments may determine that the second and third vertices aremutually exclusive (e.g., satisfying either the second vertex or thirdvertex will cancel the other vertex) and select the third vertex basedon the third vertex being associated with a greater parameter. Someembodiments may then sum the quantitative parameters of thenon-exclusive vertices (“300” and “600”) to determine the aggregatedparameter “900.”

The third UI element 3720 may display a first value 100, a second value300, and a third value 150. In some embodiments, each of the displayedvalues may be aggregated parameter values, where each respective valuemay be based on a plurality of vertices. Alternatively, some or all ofthe displayed values may be based on a single respective vertex. In someembodiments, the third UI element 3720 may be interacted with to displaya set of tasks based on one or more private conditional statementsassociated with an entity. For example, interaction with the box text3724 may cause the display of a set of private tasks 3732, as furtherdiscussed below.

Some embodiments, the UI 3700 may display the set of private tasks 3732,where the set of private tasks may be determined from an internal entityworkflow and implemented using a set of private conditional statementsor other set of private logic. For example, an entity may use or beassociated with a private set of conditional statements that determinewhether the entity is obligated to transfer or allocate an amount of aresource. In response to a determination that the entity is obligated totransfer or allocate an amount of a resource, some embodiments may senda request for a plurality of confirmation keys from a set of designatedentity representatives. Some embodiments may then transfer a UI or datainterpretable by a UI that causes the UI to update a set of privatetasks to indicate that the set of confirmation key has been requestedand that the set of confirmation keys should be sent.

Some embodiments may send a UI or send data to a UI to update a directedgraph or directed graph portion to visually indicate effects ofreceiving an event message. For example, after receiving an eventmessage indicating the satisfaction of the first vertex 3742, someembodiments may send data to the UI 3700 to cause the UI to change acolor of the first vertex 3722, and change a color of the second vertex3744. In some embodiments, the color change of the first vertex 3742 mayindicate that the first vertex is triggered by the event message.Alternatively, or in addition, the color change of the second vertex3744 may indicate that the second vertex 3744 has been made active inresponse to a most recent event message. Additionally, some embodimentsmay indicate a future program state that may be caused by an entity andmay be associated with one or more private tasks that the entity mustperform. For example, some embodiments may link the set of private tasks3732 to the third vertex 3746, where the selection of the third vertex3746 may cause the display of the set of private tasks 3732. By directlylinking private tasks to a possible outcome vertex, the UI provided bysome embodiments may provide more intuitive and efficientdecision-making for an entity.

As described above, some embodiments may determine aggregated parametersor perform other operations when detecting possible states that maycause one or more entities to be notified. In response to an entityreceiving a notification, some embodiments may perform queryingoperations to determine an event record for an event causing thenotification. Some embodiments may perform operations, such as thosedescribed further below, to query a graph-based model and obtain eventrecords based on the query with greater efficiency.

In block diagrams, illustrated components are depicted as discretefunctional blocks, but embodiments are not limited to systems in whichthe functionality described herein is organized as illustrated. Thefunctionality provided by each of the components may be provided bysoftware or hardware modules that are differently organized than ispresently depicted, for example such software or hardware may beintermingled, conjoined, replicated, broken up, distributed (e.g. withina data center or geographically), or otherwise differently organized.The functionality described herein may be provided by one or moreprocessors of one or more computers executing code stored on a tangible,non-transitory, machine readable medium. In some cases, notwithstandinguse of the singular term “medium,” the instructions may be distributedon different storage devices associated with different computingdevices, for instance, with each computing device having a differentsubset of the instructions, an implementation consistent with usage ofthe singular term “medium” herein. In some cases, third party contentdelivery networks may host some or all of the information conveyed overnetworks, in which case, to the extent information (e.g., content) issaid to be supplied or otherwise provided, the information may providedby sending instructions to retrieve that information from a contentdelivery network.

The reader should appreciate that the present application describesseveral independently useful techniques. Rather than separating thosetechniques into multiple isolated patent applications, applicants havegrouped these techniques into a single document because their relatedsubject matter lends itself to economies in the application process. Butthe distinct advantages and aspects of such techniques should not beconflated. In some cases, embodiments address all of the deficienciesnoted herein, but it should be understood that the techniques areindependently useful, and some embodiments address only a subset of suchproblems or offer other, unmentioned benefits that will be apparent tothose of skill in the art reviewing the present disclosure. Due to costsconstraints, some techniques disclosed herein may not be presentlyclaimed and may be claimed in later filings, such as continuationapplications or by amending the present claims. Similarly, due to spaceconstraints, neither the Abstract nor the Summary of the Inventionsections of the present document should be taken as containing acomprehensive listing of all such techniques or all aspects of suchtechniques.

It should be understood that the description and the drawings are notintended to limit the present techniques to the particular formdisclosed, but to the contrary, the intention is to cover allmodifications, equivalents, and alternatives falling within the spiritand scope of the present techniques as defined by the appended claims.Further modifications and alternative embodiments of various aspects ofthe techniques will be apparent to those skilled in the art in view ofthis description. Accordingly, this description and the drawings are tobe construed as illustrative only and are for the purpose of teachingthose skilled in the art the general manner of carrying out the presenttechniques. It is to be understood that the forms of the presenttechniques shown and described herein are to be taken as examples ofembodiments. Elements and materials may be substituted for thoseillustrated and described herein, parts and processes may be reversed oromitted, and certain features of the present techniques may be utilizedindependently, all as would be apparent to one skilled in the art afterhaving the benefit of this description of the present techniques.Changes may be made in the elements described herein without departingfrom the spirit and scope of the present techniques as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if X, Y,”“when X, Y,” and the like, encompass causal relationships in which theantecedent is a necessary causal condition, the antecedent is asufficient causal condition, or the antecedent is a contributory causalcondition of the consequent, e.g., “state X occurs upon condition Yobtaining” is generic to “X occurs solely upon Y” and “X occurs upon Yand Z.” Such conditional relationships are not limited to consequencesthat instantly follow the antecedent obtaining, as some consequences maybe delayed, and in conditional statements, antecedents are connected totheir consequents, e.g., the antecedent is relevant to the likelihood ofthe consequent occurring. Statements in which a plurality of attributesor functions are mapped to a plurality of objects (e.g., one or moreprocessors performing steps A, B, C, and D) encompasses both all suchattributes or functions being mapped to all such objects and subsets ofthe attributes or functions being mapped to subsets of the attributes orfunctions (e.g., both all processors each performing steps A-D, and acase in which processor 1 performs step A, processor 2 performs step Band part of step C, and processor 3 performs part of step C and step D),unless otherwise indicated. Similarly, reference to “a computer system”performing step A and “the computer system” performing step B caninclude the same computing device within the computer system performingboth steps or different computing devices within the computer systemperforming steps A and B. Further, unless otherwise indicated,statements that one value or action is “based on” another condition orvalue encompass both instances in which the condition or value is thesole factor and instances in which the condition or value is one factoramong a plurality of factors. Unless otherwise indicated, statementsthat “each” instance of some collection have some property should not beread to exclude cases where some otherwise identical or similar membersof a larger collection do not have the property, i.e., each does notnecessarily mean each and every. Limitations as to sequence of recitedsteps should not be read into the claims unless explicitly specified,e.g., with explicit language like “after performing X, performing Y,” incontrast to statements that might be improperly argued to imply sequencelimitations, like “performing X on items, performing Y on the X'editems,” used for purposes of making claims more readable rather thanspecifying sequence. Statements referring to “at least Z of A, B, andC,” and the like (e.g., “at least Z of A, B, or C”), refer to at least Zof the listed categories (A, B, and C) and do not require at least Zunits in each category. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.Features described with reference to geometric constructs, like“parallel,” “perpendicular/orthogonal,” “square”, “cylindrical,” and thelike, should be construed as encompassing items that substantiallyembody the properties of the geometric construct, e.g., reference to“parallel” surfaces encompasses substantially parallel surfaces. Thepermitted range of deviation from Platonic ideals of these geometricconstructs is to be determined with reference to ranges in thespecification, and where such ranges are not stated, with reference toindustry norms in the field of use, and where such ranges are notdefined, with reference to industry norms in the field of manufacturingof the designated feature, and where such ranges are not defined,features substantially embodying a geometric construct should beconstrued to include those features within 15% of the definingattributes of that geometric construct. The term “set” may indicate asingle item or a plurality of items, e.g., “set of widgets” may indicateonly one widget or may indicate multiple widgets. The terms “first”,“second”, “third,” “given” and so on, if used in the claims, are used todistinguish or otherwise identify, and not to show a sequential ornumerical limitation. As is the case in ordinary usage in the field,data structures and formats described with reference to uses salient toa human need not be presented in a human-intelligible format toconstitute the described data structure or format, e.g., text need notbe rendered or even encoded in Unicode or ASCII to constitute text;images, maps, and data-visualizations need not be displayed or decodedto constitute images, maps, and data-visualizations, respectively;speech, music, and other audio need not be emitted through a speaker ordecoded to constitute speech, music, or other audio, respectively.Computer implemented instructions, commands, and the like are notlimited to executable code and can be implemented in the form of datathat causes functionality to be invoked, e.g., in the form of argumentsof a function or API call.

In this patent, to the extent any U.S. patents, U.S. patentapplications, or other materials (e.g., articles) have been incorporatedby reference, the text of such materials is only incorporated byreference to the extent that no conflict exists between such materialand the statements and drawings set forth herein. In the event of suchconflict, the text of the present document governs, and terms in thisdocument should not be given a narrower reading in virtue of the way inwhich those terms are used in other materials incorporated by reference.

The present techniques will be better understood with reference to thefollowing enumerated embodiments:

A-1. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by one or more processors effectuateoperations comprising: determining, with a computer system, that anevent has occurred; selecting, with the computer system, aself-executing protocol among a plurality of self-executing protocolsbased on the event, wherein: the self-executing protocol comprises a setof conditions, a set of entities, a set of vertices, and a set ofdirected graph edges connecting the set of vertices, the set of verticescomprise different respective subsets of the conditions, the set ofentities are encoded in an associative array, the set of conditions areencoded in an associative array, the set of vertices are encoded as aserialized array of vertices, wherein the serialized array of verticesis in a serialized data format in persistent storage, selecting is basedon whether the event satisfies any of the set of conditions;deserializing, with the computer system, the serialized array ofvertices to generate a directed graph in a non-persistent memory,wherein the directed graph encodes the set of conditions, set ofvertices, set of entities, and set of directed edges; determining, withthe computer system, a set of triggerable vertices from the vertices ofthe directed graph in the non-persistent memory; determining, with thecomputer system, a set of triggered vertices from the set of triggerablevertices based on which of the set of triggerable vertices areassociated with the set of conditions satisfied by the event; updating,with the computer system, the directed graph in the non-persistentmemory based on the set of triggered vertices, wherein updating thedirected graph comprises, for each respective triggered vertex of theset of triggered vertices: updating a first value associated with therespective triggered vertex based on the event, where the first valueindicates whether the respective triggered vertex is triggerable;updating a respective adjacent vertex to indicate that the respectiveadjacent vertex is triggerable, wherein the respective adjacent vertexis associated with a directed graph edge of the respective triggeredvertex; updating, with the computer system, the serialized array ofvertices by serializing the directed graph in the non-persistent memoryafter updating the directed graph in the non-persistent memory based onthe set of triggered vertices; and persisting, with the computer system,the serialized array of vertices to the persistent storage after theserialized array of vertices is updated by serialization.A-2. The medium of embodiment A-1, wherein: a first vertex in the set ofvertices is indicated to not be triggerable by a first set of values,wherein each of the first set of values indicate whether a vertex in theset of vertices is triggerable; and the directed graph in thenon-persistent memory does not include the first vertex of theserialized array of vertices.A-3. The medium of any of embodiments A-1 to A-2, wherein the serializedarray of vertices comprises an array of subarrays, wherein each subarraycomprises a head vertex of a directed graph edge of the set of directedgraph edges, a tail vertex of the directed graph edge, a labelassociated with the directed graph edge, and a valence value indicatinga number of other edges associated with the directed graph edge.A-4. The medium of any of embodiments A-1 to A-3, wherein determiningthat an event occurred further comprises: receiving an event messagefrom a publisher, wherein the publisher is identified by a publisheridentifier; determining whether the publisher is associated with one ofa set of authorized publishers based on the publisher identifier; andauthorizing the event message based on a determination that thepublisher identifier is associated with one of the set of authorizedpublishers.A-5. The medium of any of embodiments A-1 to A-4, wherein the operationsfurther comprise: receiving an event message from a publisher, whereinthe event message is associated with a signature value and a publisheridentifier; retrieving a cryptographic certificate based on thepublisher identifier; computing a cryptographic hash value based on thesignature value; and authenticating the event message based on thecryptographic hash value and the cryptographic certificate.A-6. The medium of any of embodiments A-1 to A-5, wherein determiningthe set of triggered vertices comprises: determining a first set ofvertices in the directed graph in the non-persistent memory, whereineach respective vertex of the first set of vertices is indicated as ahead vertex by one of the set of directed graph edges; and determiningthe set of triggerable vertices based on the first set of vertices byfiltering out a set of tail vertices from the first set of vertices,wherein each of the set of tail vertices is indicated as a tail vertexby one of the set of directed graph edges.A-7. The medium of any of embodiments A-1 to A-6, wherein the serializedarray of vertices is stored in a tamper-evident data store beingexecuted by a set of peer nodes, wherein the tamper-evident data storecomprises a directed acyclic graph of cryptographic hash pointers, andwherein deserializing the serialized array of vertices comprises using afirst node of the set of peer nodes to deserialize the serialized arrayof vertices, and wherein the operations further comprising transmittingthe serialized array of vertices from the first node to another node ofthe set of peer nodes after updating the serialized array of vertices.A-8. The medium of any of embodiments A-1 to A-7, the operations furthercomprising receiving an event message, wherein receiving the eventmessage comprises receiving a request that comprises the event message,and wherein the request comprises a method identifier and a hostidentifier, wherein the method identifier indicates that the requestcomprises an amount of data to modify data stored by the system, andwherein the host identifier indicates a host of the self-executingprotocol.A-9. The medium of any of embodiments A-1 to A-8, the operations furthercomprising receiving an event message, wherein the event messagecomprises a routing key, and wherein a data broker stores the eventmessage in a queue, and wherein a protocol broker transmits the eventmessage to an API associated with the self-executing protocol based onthe routing key.A-10. The medium of any of embodiments A-1 to A-9, wherein determiningthe set of triggered vertices comprises determining the set of triggeredvertices based on a second set of values, wherein each of the second setof values is associated with one of a set of vertices of the directedgraph in the non-persistent memory, and wherein one of the second set ofvalues indicate that one of the set of vertices of the directed graph inthe non-persistent memory is triggerable.A-11. The medium of any of embodiments A-1 to A-10, wherein determiningthat the event has occurred comprises determining that a conditionexpiration threshold has been satisfied, and wherein the conditionexpiration threshold is associated with a first condition of a firsttriggerable vertex, and wherein the event does not satisfy the firstcondition.A-12. The medium of any of embodiments A-1 to A-11, the operationsfurther comprising updating an array of previously-triggered verticesbased on a vertex identifier associated with the respective triggeredvertex.A-13. The medium of any of embodiments A-1 to A-12, the operationsfurther comprising generating an initial directed graph based on aninitial set of vertices, wherein the initial set of vertices isdifferent from the serialized array of vertices.A-14. The medium of any of embodiments A-1 to A-13, wherein a vertex ofthe directed graph stored in the non-persistent memory comprises acondition of the set of conditions.A-15. The medium of any of embodiments A-1 to A-14, the operationsfurther comprising updating a third set of values associated with theserialized array of vertices, wherein the third set of values indicatethat the respective triggered vertex is not triggerable.A-16. The medium of any of embodiments A-1 to A-15, wherein updating therespective adjacent vertex comprises setting a plurality of statusesassociated with a plurality of vertices other than the respectivetriggered vertex as not triggerable.A-17. The medium of any of embodiments A-1 to A-16, wherein updating thefirst value comprises updating the first value to indicate that therespective triggered vertex remains triggerable after updating theserialized array of vertices.A-18. The medium of embodiment A-17, wherein updating the respectiveadjacent vertex comprises decreasing a second value, wherein the secondvalue indicates a state of the self-executing protocol.A-19. The medium of any of embodiments A-1 to A-18, the operationsfurther comprising updating a set of previous events based on the event,wherein the set of previous events comprises a plurality of previousevents that caused a state change in the self-executing protocol,wherein the set of previous events comprises a time during which theevent occurred.A-20. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by one or more processors effectuateoperations comprising: determining, with a computer system, that anevent has occurred; selecting, with the computer system, aself-executing protocol among a plurality of self-executing protocolsbased on the event, wherein: the self-executing protocol comprises a setof conditions, a set of entities, a set of vertices, and a set ofdirected graph edges connecting the set of vertices, the set of verticescomprise different respective subsets of the conditions, the set ofentities are encoded in an associative array, the set of conditions areencoded in an associative array, the set of vertices are encoded as aserialized array of vertices, wherein the serialized array of verticesis in a serialized data format in persistent storage, selecting is basedon whether the event satisfies any of the set of conditions;deserializing, with the computer system, the serialized array ofvertices to generate a directed graph in a non-persistent memory,wherein the directed graph encodes the set of conditions, set ofvertices, set of entities, and set of directed edges; determining, withthe computer system, a set of triggerable vertices from the vertices ofthe directed graph in the non-persistent memory; determining, with thecomputer system, a set of triggered vertices from the set of triggerablevertices based on which of the set of triggerable vertices areassociated with the set of conditions satisfied by the event; updating,with the computer system, the directed graph in the non-persistentmemory based on the set of triggered vertices, wherein updating thedirected graph comprises, for each respective triggered vertex of theset of triggered vertices: updating a first value associated with therespective triggered vertex based on the event, where the first valueindicates whether the respective triggered vertex is triggerable;updating a respective adjacent vertex to indicate that the respectiveadjacent vertex is triggerable, wherein the respective adjacent vertexis associated with a directed graph edge of the respective triggeredvertex; updating, with the computer system, the serialized array ofvertices by serializing the directed graph in the non-persistent memoryafter updating the directed graph in the non-persistent memory based onthe set of triggered vertices; and persisting, with the computer system,the serialized array of vertices to the persistent storage after theserialized array of vertices is updated by serialization.A-21. A method to perform the operations of any of the embodiments A-1to A-19.A-22. A system, comprising: one or more processors; and memory storinginstructions that when executed by the processors cause the processorsto effectuate operations comprising: the operations of any one ofembodiments A-1 to A-19.B-1. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by one or more processors effectuateoperations comprising: obtaining, with a computer system, a set ofconditional statements, wherein: a conditional statement of the set ofconditional statements is associated with an outcome subroutine thatspecifies operations in each of one or more branches of the conditionalstatement, a set of index values index the set of conditionalstatements, and a first outcome subroutine of a first conditionalstatement of the set of conditional statements uses a first index valueof the set of index values, wherein the first index value is associatedwith a second conditional statement of the set of conditionalstatements; executing, with the computer system, a program instance ofan application based on the set of conditional statements, whereinprogram state data of the program instance comprises: a set of verticesand a set of directed graph edges, wherein each of the set of verticescomprises a identifier value and is associated with one of the set ofconditional statements, and wherein each of the set of directed graphedges associates a pair of the set of vertices and a direction from atail vertex of the pair to a head vertex of the pair, a set of statuses,wherein each of the set of statuses is associated with one of the set ofvertices, a set of vertex categories, wherein each of the set of vertexcategories is a category value and is associated with a respectivevertex of the set of vertices and is determined based a respectiveconditional statement of the respective vertex, and a set of scores,wherein each respective score of the set of scores is associated with arespective vertex and is based a respective conditional statement of therespective vertex; updating, with the computer system, the program statedata based on a set of inputs comprising a first input, wherein updatingthe program state data comprises: modifying a status of a first vertexof the set of vertices based on the first input, updating a vertexadjacent to the first vertex; and determining, with the computer system,an outcome score based on the set of scores after updating the programstate data.B-2. The medium of embodiment B-1, wherein the status is a first status,and wherein updating the program state data comprises updating theprogram state data based on the first status, and wherein the operationsfurther comprise: modifying a second status of a second vertex of theset of vertices based on a second input; updating a third vertexadjacent to the second vertex, wherein determining the outcome scorecomprises determining the outcome score after updating the third vertex.B-3. The medium of embodiment B-2, wherein the operations furthercomprise determining the first input based on a probability valueassociated with one of the set of vertex categories.B-4. The medium of any of embodiments B-2 to B-3, wherein the outcomescore is a first outcome score, and wherein the program state data is ina first state before modifying the program state data, and wherein theoperations further comprise: updating a neural network parameter afterupdating the third vertex based on the first outcome score, wherein theneural network parameter comprises a set of probability values assignedto each of a subset of vertices of the set of vertices; determining athird input based on the neural network parameter; updating the programstate data that is in the first state based on the third input; anddetermining a second outcome score after updating the program state databased on the third input.B-5. The medium of any of embodiments B-1 to B-4, wherein executing theprogram instance comprises executing the program instance during a firstiteration, and wherein the set of inputs is a first set of inputs, andwherein the outcome score is a first outcome score, and wherein theprogram state data is in a first state before modifying the programstate data, and wherein the operations further comprise: executing theprogram instance during a second iteration by updating the program statedata based on a second set of inputs, wherein the program state data isin the first state before updating the program state data based on thesecond set of inputs; determining a second outcome score based on thesecond set of inputs; and determining a multi-iteration score based onthe first outcome score and the second outcome score.B-6. The medium of embodiment B-5, wherein the operations furthercomprise: acquiring a third score; and determining a possible eventbased the third score using a probability distribution, wherein theprobability distribution is based on the multi-iteration score.B-7. The medium of embodiment B-6, wherein determining the possibleevent comprises using a neural network that is trained using inputsbased on the first outcome score and the second outcome score, andwherein the neural network is trained using a training output based onthe first set of inputs and the second set of inputs.B-8. The medium of any of embodiments B-5 to B-7, wherein: the first setof inputs is associated with a first weighting value; the second set ofinputs is associated with a second weighting value; and determining themulti-iteration score is based on the first weighting value and thesecond weighting value.B-9. The medium of any of embodiments B-5 to B-8, the operations furthercomprising determining a probability distribution function based on themulti-iteration score.B-10. The medium of any of embodiments B-1 to B-9, wherein modifying thestatus of the first vertex comprises determining a set of events,wherein each of the set of events satisfies a condition of the set ofconditional statements.B-11. The medium of any of embodiments B-1 to B-10, wherein acquiringthe set of conditional statements comprises: acquiring an event; for arespective self-executing protocol of a plurality of self-executingprotocols, determining whether the event satisfies a conditionassociated with the respective self-executing protocol; and acquiringthe set of conditional statements associated with the respectiveself-executing protocol in response to the event satisfying thecondition associated with the respective self-executing protocol.B-12. The medium of any of embodiments B-1 to B-11, wherein acquiringthe set of conditional statements comprises: acquiring an entityidentifier; for a respective self-executing protocol of a plurality ofself-executing protocols, determining whether the entity identifier isin a respective set of entities associated with the respectiveself-executing protocol; and acquiring the set of conditional statementsassociated with the respective self-executing protocol in response tothe entity identifier being in the respective set of entities associatedwith the respective self-executing protocol.B-13. The medium of any of embodiments B-1 to B-12, the operationsfurther comprising: acquiring a first entity identifier and a secondentity identifier; selecting a first set of self-executing protocolsfrom a plurality of self-executing protocols, wherein each of the firstset of self-executing protocols comprises a first set of entities thatcomprises the first entity identifier; determining a second set ofself-executing protocols from the plurality of self-executing protocols,wherein each of the second set of self-executing protocols comprises asecond set of entities that comprises the second entity identifier; anddetermining a set of intermediary entities, wherein each of the set ofintermediary entities is in a set of entities of the first set ofself-executing protocols, and wherein each of the set of intermediaryentities is in a set of entities of the second set of self-executingprotocols.B-14. The medium of any of embodiments B-1 to B-13, wherein modifyingthe status of the first vertex comprises setting a first status toindicate that a first entity fails to transfer a score to a secondentity.B-15. The medium of any of embodiments B-1 to B-14, the operationsfurther comprising: detecting a pattern based on a plurality of the setof vertices and a plurality of the set of directed graph edges; andsending a message indicating that the pattern is detected.B-16. The medium of any of embodiments B-1 to B-15, the operationsfurther comprising determining a measure of central tendency based onthe outcome score.B-17. The medium of any of embodiments B-1 to B-16, the operationsfurther comprising determining a kurtosis value based on the outcomescore, wherein the kurtosis value correlates with a ratio of a firstvalue and a second value, wherein the first value is based on a measureof central tendency, and wherein the second value is based on a measureof dispersion.B-18. The medium of any of embodiments B-1 to B-17, the operationsfurther comprising: acquiring an event message via an applicationprotocol interface; determining a first set of events based on the eventmessage, wherein the set of inputs does not include the first set ofevents; and updating the program state data based on the first set ofevents, wherein the program state data is updated based on the set ofinputs after the program state data is updated with the first set ofevents.B-19. The medium of any of embodiments B-1 to B-18, the operationsfurther comprising: modifying a first status of a first vertex of theset of vertices to indicate that the first vertex is triggered;modifying a second status of a second vertex of the set of vertices toindicate that the second vertex is triggered; and in response to thefirst status and the second status being modified to indicate they aretriggered, triggering a third vertex that is adjacent to the firstvertex and the second vertex.B-20. A method comprising: acquiring a set of conditional statements,wherein: a conditional statement of the set of conditional statements isassociated with an outcome subroutine and an index value of a set ofindex values, and a first outcome subroutine of a first conditionalstatement of the set of conditional statements uses a first index valueof the set of index values, wherein the first index value is associatedwith a second conditional statement of the set of conditionalstatements; executing a program instance of an application based on theset of conditional statements, wherein program state data of the programinstance comprises: a set of vertices and a set of directed graph edges,wherein each of the set of vertices comprises a identifier value and isassociated with one of the set of conditional statements, and whereineach of the set of directed graph edges associates a pair of the set ofvertices and a direction from a tail vertex of the pair to a head vertexof the pair, a set of statuses, wherein each of the set of statuses isassociated with one of the set of vertices, and a set of vertexcategories, wherein each of the set of vertex categories is a categoryvalue and is associated with a respective vertex of the set of verticesand is determined based a respective conditional statement of therespective vertex, a set of scores, wherein each respective score of theset of scores is associated with a respective vertex and is based arespective conditional statement of the respective vertex; updating theprogram state data based on a set of inputs comprising a first input,wherein updating the program state data comprises: modifying a status ofa first vertex of the set of vertices based on the first input, updatinga vertex adjacent to the first vertex; and determining an outcome scorebased on the set of scores after updating the program state data.B-21. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by one or more processors effectuateoperations comprising: obtaining, with one or more processors,identifiers of a plurality of entities; obtaining, with one or moreprocessors, a plurality of symbolic artificial intelligence (AI) models,wherein: each of the plurality of symbolic AI models is configured toproduce outputs responsive to inputs based on events caused by at leastone of the plurality of entities, at least some of the plurality ofentities are associated with outputs of respective symbolic AI models,and at least some of the plurality of entities have respective scorescorresponding to the respective outputs of the symbolic AI models;obtaining, with one or more processors, a plurality of scenarios,wherein: each scenario comprises simulated inputs corresponding to oneor more simulated events, and at least some scenarios comprise aplurality of simulated inputs; determining, with one or more processors,a population of scores of a given entity among the plurality ofentities, wherein respective members of the population of scorescorrespond to respective outputs of the plurality of symbolic AI models,and wherein the respective outputs correspond to respective scenariosamong the plurality of scenarios; and storing, with one or moreprocessors, the population of scores in memory.B-22. The medium of embodiment B-21, wherein at least one of theplurality of symbolic AI models comprises: a set of vertices and a setof directed graph edges, wherein each of the set of vertices comprises aidentifier value and is associated with one of a set of conditionalstatements, and wherein each of the set of directed graph edgesassociates a pair of the set of vertices and a direction from a tailvertex of the pair to a head vertex of the pair; a set of statuses,wherein each of the set of statuses is associated with one of the set ofvertices; a set of vertex categories, wherein each of the set of vertexcategories is a category value and is associated with a respectivevertex of the set of vertices and is determined based a respectiveconditional statement of the respective vertex; and a set of scores,wherein each respective score of the set of scores is associated with arespective vertex and is based a respective conditional statement of therespective vertex.B-23. The medium of any of embodiments B-21 to B-22, wherein obtainingthe plurality of scenarios comprises: determining a first simulatedinput for a first model of the plurality of symbolic AI models based ona multi-iteration score associated with the first model, wherein thefirst model is in a first state before updating the first model based onthe first simulated input; update the first model based on the firstsimulated input to advance the first model to a second state, whereinthe second state is different from the first state; determine a secondinput, wherein the second input may be selected based on scoresassociated with each of a set of possible states associated with thefirst state; update the first model when it is in the second state basedon the second input to advance the second model to a third state,wherein the third state is different from the first state and the secondstate, and wherein the third state satisfies a terminal state criterion,and wherein a terminal state value is associated with the third state;and update the score associated with the first model based on theterminal state value; and determining a scenario of the plurality ofscenarios based on the score.B-24. The medium of embodiment B-23, wherein determining a first set ofsimulated inputs comprises determining the first set of inputs based ona first term and a second term, wherein the first term is based on acount of simulations executed that started from the first state and thesecond term is based on a score value associated with the third state.B-25. The medium of any of embodiments B-21 to B-24, wherein determiningthe population of scores comprises using a convolutional neural networkto determine a respective score based on values in a respective model ofthe symbolic AI models.B-26. The medium of any of embodiments B-21 to B-25, the operationsfurther comprising: fuzzifying the population of scores to provide a setof fuzzified inputs, wherein fuzzifying the outputs comprises using amembership function to determine a degree of membership, and wherein thefuzzified inputs comprises the degree of membership; determine afuzzified outcome score based on the degree of membership using aninference engine, wherein the inference comprises a set of executablerules that may be matched to the fuzzified inputs; and determine a labelassociated with a smart contract based on the fuzzified outcome score.B-27. The medium of any of embodiments B-21 to B-26, wherein obtainingthe plurality of scenarios comprises: determining a first scenario for afirst symbolic AI model of the plurality of AI models based on a firstset of weights corresponding to each of a set of categories, wherein thefirst symbolic AI model comprises a first plurality of the set ofcategories; and determining a second scenario for a second symbolic AImodel of the plurality of AI models based on the first set of weights,wherein the second symbolic AI model comprises a second plurality of theset of categories.B-28. The medium of any of embodiments B-21 to B-27, wherein determiningthe simulated input comprises using a decision tree, wherein thedecision tree comprises a first tree node and a second tree node, andwherein the first tree node is associated with a first score, andwherein the first tree node is associated with a second score andwherein the operations further comprise: determining whether the firstscore is greater than a second score; and in response to the first scorebeing greater than the second score, determining the simulated inputbased on a value associated with the first tree node.B-29. The medium of any of embodiments B-21 to B-28, the operationsfurther comprising updating a set of parameters of a neural networkbased on the population of scores, wherein the neural network provides aweighting value associated with a decision to cancel a self-executingprotocol.B-30. The medium of embodiment B-29, wherein determining the populationof scores of a given entity among the plurality of entities comprisesdetermining a sum of the scores.B-31. A method to perform any of the operations of embodiments B-21 toB-30.B-32. A method to perform any of the operations of embodiments B-1 toB-19.B-33. A system, comprising: one or more processors; and memory storinginstructions that when executed by the processors cause the processorsto effectuate operations comprising: the operations of any one ofembodiments B-1 to B-19.B-34. A system, comprising: one or more processors; and memory storinginstructions that when executed by the processors cause the processorsto effectuate operations comprising: the operations of any one ofembodiments B-21 to B-30.E-1. A tangible, non-transitory, machine-readable medium storinginstructions that, when executed by a computing system, effectuateoperations comprising: obtaining, with a computing system, program stateof a self-executing protocol, wherein the program state encodes: a setof conditional statements; a set of entities, wherein the set ofentities comprises a first entity; a directed graph, the directed graphcomprising: a set of vertices, wherein each respective vertex of the setof vertices is associated with a respective category label of a set ofmutually exclusive categories; a set of directed edges connectingrespective pairs of vertices among the set of vertices; obtaining, withthe computing system, an entity profile of the first entity, wherein:the entity profile comprises a first graph portion template, the firstgraph portion template comprises a first vertex template and an edgetemplate, the first vertex template is associated in memory with a firstcategory label of the set of mutually exclusive category labels, and theedge template specifies an edge direction to or from a vertex matchingthe first vertex template; determining, with the computing system,whether the first graph portion template matches a graph portion in thedirected graph based on a first vertex of the directed graph matchingthe first vertex template and a first directed edge of the directedgraph matching the edge template; determining, with the computingsystem, an outcome score based on the first graph portion templatematching the graph portion in the directed graph; determining, with thecomputing system, whether the outcome score satisfies an outcome scorethreshold; and in response to the outcome score satisfying the outcomescore threshold, storing, with the computing system, a value indicatingthat the outcome score satisfies the outcome score threshold.E-2. The medium of embodiment E-1, wherein: the set of vertices are aset of norm vertices; the first vertex is a first norm vertex; the setof entities include parties to the self-executing protocol; theoperations further comprising: obtaining a plurality of self-executingprotocol programs comprising a plurality of directed graphs, whereineach respective directed graph of the plurality of directed graphs isassociated with a respective set of entities that comprises the firstentity; determining the first graph portion template based on theplurality of directed graphs, wherein a second norm vertex of theplurality of directed graphs matches the first norm vertex template ofthe first graph portion template, and wherein a condition of the secondnorm vertex is indicated to have been failed by the first entity basedon an event message; and determining an outcome determination parameterbased on a number of times that the first graph portion template matcheswith a respective graph portion in the plurality of self-executingprotocol programs, wherein determining the outcome score comprisesdetermining the outcome score based on the outcome determinationparameter.E-3. The medium of any of embodiments E-1 to E-2, the operations furthercomprising: obtaining a plurality of self-executing protocol programscomprising a plurality of directed graphs, wherein each respectiveself-executing protocol program of the plurality of self-executingprotocol programs comprises a respective directed graph of the pluralityof directed graphs; determining the first graph portion template basedon the plurality of self-executing protocol programs, wherein a secondvertex of a second directed graph of the plurality of directed graphsmatches the first vertex template, and wherein a third vertex of theplurality of directed graphs matches a second vertex template, andwherein a condition of the third vertex is indicated as having beensatisfied based on an event message; and determining an outcomedetermination parameter based on a number of times that the first graphportion template matches with a respective graph portion in theplurality of self-executing protocol programs, wherein determining theoutcome score comprises determining the outcome score based on theoutcome determination parameter.E-4. The medium of any of embodiments E-1 to E-3, wherein the entityprofile is a first entity profile, and wherein the operations furthercomprise: determining a transaction score based on the directed graph,wherein the transaction score is associated with a transaction betweenthe first entity and a second entity; and updating an associationbetween the first entity profile and a second entity profile based onthe transaction score, wherein the second entity profile is associatedwith the second entity.E-5. The medium of any of embodiments E-1 to E-4, the operations furthercomprising: determining whether the first entity has failed aconditional statement associated with a second vertex of the directedgraph; and in response to a determination that the first entity hasfailed the conditional statement, updating an entity score of an entitygraph, wherein the entity score is associated with the first entity, andwherein the entity graph comprises a plurality of entity vertices, andwherein each respective entity vertex of the plurality of entityvertices is associated with a respective entity profile.E-6. The medium of embodiment E-5, wherein the entity graph is stored ona distributed, tamper-evident ledger, and wherein updating the entityscore comprises: obtaining an encryption key associated with the firstentity; obtaining a previous entity score from the distributed,tamper-evident ledger based on the encryption key; and updating theentity score based on the previous entity score.E-7. The medium of any of embodiments E-5 to E-6, wherein the entitygraph is stored on a distributed, tamper-evident ledger, and wherein theoperations further comprise: determining whether the entity scoresatisfies an entity score threshold of a verification entity; and inresponse to the entity score satisfying the entity score threshold,storing an indicator that the first entity satisfies the entity scorethreshold of the verification entity.E-8. The medium of any of embodiments E-5 to E-7, the operations furthercomprising: determining whether the entity score satisfies an entityscore threshold of a verification entity; and sending a message to anapplication program interface, wherein the message indicates that thefirst entity satisfies the entity score threshold of the verificationentity.E-9. The medium of any of embodiments E-5 to E-8, wherein the entityprofile is a first entity profile, and wherein the operations furthercomprise: determining a second entity score associated with the firstentity, wherein the first entity profile does not comprise the secondentity score; obtaining a passkey value; and in response to receivingthe passkey value, sending a message comprising the second entity score.E-10. The medium of any of embodiments E-1 to E-9, wherein determiningthe outcome score comprises determining the outcome score using a neuralnetwork based on a feature set, wherein: determining the feature set,wherein determining the feature set comprises determining whether thefirst graph portion template matches a graph portion in the directedgraph; and the neural network is trained on a plurality of directedgraphs of a plurality of a self-executing protocol programs, wherein thefirst graph portion template matches a graph portion of a subset of theplurality of directed graphs.E-11. The medium of any of embodiments E-1 to E-10, wherein determiningthe outcome score comprises: generating a set of embeddings based on aset of vertices of the directed graph, wherein each vertex of the set ofvertices is associated with an embedding of the set of embeddings, andwherein each embedding comprises a vector; determining a feature setbased on the set of embeddings; and determining the outcome score usinga neural network based on the feature set.E-12. The medium of any of embodiments E-1 to E-11, wherein the entityprofile is a first entity profile and the outcome score is a firstoutcome score, and wherein the operations further comprise: obtaining asecond entity profile, wherein the second entity profile is associatedwith a second entity, and wherein the second entity profile comprisesthe first graph portion template, and wherein a second outcomedetermination parameter is determined based on the first graph portiontemplate; determining a second outcome score associated with the secondentity profile based on the second outcome determination parameter; andselecting the first entity based on the first outcome score and thesecond outcome score.E-13. The medium of any of embodiments E-1 to E-12, the operationsfurther comprising: sampling the directed graph to determine a set ofsubgraphs; determining a vector based on the set of subgraphs using askip-gram model; and determining the outcome score using a neuralnetwork based on the vector.E-14. The medium of any of embodiments E-1 to E-13, wherein the firstgraph portion template further comprises a second vertex template,wherein the second vertex template is associated with a second categorylabel of the set of mutually exclusive category labels, and wherein thesecond category label is different from the first category label.E-15. The medium of any of embodiments E-1 to E-14, the operationsfurther comprising: updating the entity profile based a history of thefirst entity; storing the entity profile on a centralized computingplatform, wherein the entity profile is associated with an entityidentifier; and updating a value associated with the entity identifier,wherein the value is stored on a distributed, tamper-evident ledgeroperating on a distributed computing platform.E-16. The medium of any of embodiments E-1 to E-15, wherein the entityprofile is a first entity profile, and wherein the operations furthercomprising: obtaining a second entity profile; determining whether a setof entity similarity criteria is satisfied based on the first entityprofile and the second entity profile; and storing value indicating thatthe first entity profile and the second entity profile satisfy the setof entity similarity criteria.E-17. The medium of any of embodiments E-1 to E-16, wherein the firstgraph portion template further comprises a second vertex template,wherein the second vertex template is not connected to the first vertextemplate in the first graph portion template by any edge templates.E-18. The medium of any of embodiments E-1 to E-17, wherein the directedgraph is a first self-executing protocol directed graph, and wherein theoperations further comprise: determining a first transaction amountbetween the first entity and a second entity based on the firstself-executing protocol directed graph; determining a second transactionamount between the second entity and a third entity based on a secondself-executing protocol directed graph; updating a first associationbetween the first entity and the second entity of an entity graph basedon the first transaction amount; updating a second association betweenthe second entity and the third entity of the entity graph based on thesecond transaction amount; and determining whether the first entity isassociated with the third entity based on the first association, thefirst transaction amount, the second association, and the secondtransaction amount.E-19. The medium of embodiment 18, the operations further comprising:determining whether the first entity has failed a conditional statementassociated with the first vertex; in response to a determination thatthe first entity has failed the conditional statement, updating anentity score is associated with the first entity; and sending a messageto the third entity in response to the updating of the entity scoreassociated with the first entity.E-20. A method to perform the operations of any of the embodiments E-1to E-19.E-21. A system comprising: one or more processors; and memory storinginstructions that, when executed by at least one of the one or moreprocessors, causes at least one of the one or more processors toeffectuate any of the operations of embodiments E-1 to E-19.F-1. A tangible, non-transitory, machine-readable medium storinginstructions that, when executed by a computing system, effectuateoperations comprising: obtaining, with a computing system, a set ofconditions; obtaining, with the computing system, a first cross-programentity identifier of a first entity, wherein the first cross-programentity identifier is unique amongst a set of cross-program entityidentifiers of a decentralized computing platform; obtaining, with thecomputing system, a set of directed graphs of a set of self-executingprotocols comprising a first self-executing protocol and a secondself-executing protocol that are executed on the decentralized computingplatform, wherein: each respective self-executing protocol of the set ofself-executing protocols comprises data of a respective directed graphof the respective self-executing protocol, and the first cross-programentity identifier is associated with a first program-specific entityidentifier of the first self-executing protocol and a secondprogram-specific entity identifier of the second self-executingprotocol; determining, with the computing system, that the set ofconditions is applicable to the first entity based on the firstcross-program entity identifier; determining, with the computing system,whether the set of conditions are satisfied based on whether a graphportion associated with the set of directed graphs corresponds to agraph portion template of the set of conditions; and in response to adetermination that the graph portion corresponds to the graph portiontemplate, storing, with the computing system, an indication that thefirst entity violated the set of conditions in a profile of the firstentity using the first cross-program entity identifier.F-2. The medium of embodiment F-1, the operations further comprising:determining a first set of geographic locations associated with thefirst entity based on the first cross-program entity identifier; anddetermining whether the first set of geographic locations satisfies afirst condition of the set of conditions based on whether the first setof geographic locations is within a geofence indicated by the firstcondition, wherein the indication indicates that the first entityviolated the set of conditions based on whether the first set ofgeographic locations satisfies the first condition.F-3. The medium of any of embodiments F-1 to F-2, the operations furthercomprising determining a second set of counterparty entities based onthe set of self-executing protocols, wherein each counterparty entity ofthe set of counterparty entities is associated with a transaction withthe first entity.F-4. The medium of any of embodiments F-1 to F-3, wherein obtaining theset of conditions comprises: obtaining a governing document; determininga set of entity categories using a natural language processing modelbased on governing document; and determining a condition of the set ofconditions based on the set of entity categories.F-5. The medium of any of embodiments F-1 to F-4, the operations furthercomprising: obtaining a governing document; selecting a section of thegoverning document based on a text header indicated by a set of textsizes or text spacings; and determining a condition of the set ofconditions based on the section of the governing document.F-6. The medium of any of embodiments F-1 to F-5, the operations furthercomprising: obtaining a first profile associated with the firstcross-program entity identifier; obtaining a natural language document,wherein the natural language document comprises a verifying agentidentifier and an entity name associated with the first cross-programentity identifier; using a natural language processing model to parsethe natural language document to determine the verifying agentidentifier and the entity name; sending a first message comprising theentity name to an application program interface (API) of a third-partyentity based on the verifying agent identifier; and obtaining a secondmessage from the third-party entity indicating that the entity name isvalid and, in response, setting the first profile associated with thefirst cross-program entity identifier as a verified profile.F-7. The medium of any of embodiments F-1 to F-6, the operations furthercomprising sending a notification message to a second entity indicatingthat the first entity failed the set of conditions.F-8. The medium of any of embodiments F-1 to F-7, the operations furthercomprising: sending a first message comprising data of a pendingtransaction to a third entity, wherein a participant of the pendingtransaction is associated with the first cross-program entityidentifier; obtaining a second message from the third entity, whereinthe second message indicates that the third entity has verified thepending transaction; and in response to receiving the second message,storing a value indicating that the transaction was verified by thethird entity on a distributed, tamper-evident data structure.F-9. The medium of any of embodiments F-1 to F-8, the operations furthercomprising: determining, after a threshold duration of time afterdetermining whether the set of conditions are satisfied, whether the setof conditions are satisfied a second time; and in response to adetermination that the set of conditions are satisfied, setting a valueto indicate that a resource transfer or allocation of a pendingtransaction is permitted, wherein a participant of the pendingtransaction is associated with the first cross-program entityidentifier.F-10. The medium of any of embodiments F-1 to F-9, the operationsfurther comprising: determining that a variable of the set of conditionsis not stored in data of a smart self-executing protocol; compute avalue for the variable using a function encoded in the set ofconditions; determining whether a the value satisfies a threshold valueof a first condition; and in response to a determination that the valuesatisfies the threshold value, storing a value indicating that the firstentity satisfies the first condition to a persistent storage.F-11. The medium of any of embodiments F-1 to F-10, the operationsfurther comprising: obtaining an additional governing document; updatingthe set of conditions based on the additional governing document; anddetermining whether the updated set of conditions is satisfied.F-12. The medium of any of embodiments F-1 to F-11, wherein determiningwhether the set of conditions is satisfied further comprises:determining a first score change of the first self-executing protocol;determining that the first score change is associated with the firstentity based on an association between the first program-specific entityidentifier and the first cross-program entity identifier; determining asecond score change of the second self-executing protocol; determiningthat the second score change is associated with the first entity basedon an association between the second program-specific entity identifierand the first cross-program entity identifier; and determining whetherthe first entity satisfies the set of conditions based on the firstscore change and the second score change.F-13. The medium of any of embodiments F-1 to F-12, the operationsfurther comprising: determine a summation based on the first scorechange and the second score change, wherein determining whether the setof conditions is satisfied comprises determining whether the summationsatisfies a threshold value.F-14. The medium of any of embodiments F-1 to F-13, wherein a set ofentities participating in the first self-executing protocol do not havepermission to view the first cross-program entity identifier and thecomputer system prevents such viewing responsive to the lack ofpermission.F-15. The medium of any of embodiments F-1 to F-14, the operationsfurther comprising: determining whether a first value of a transactionsatisfies a warning threshold, wherein the warning threshold is based ona condition of the set of conditions; and sending a message indicatingthat the warning threshold has been satisfied to the first entity.F-16. The medium of any of embodiments F-1 to F-15, the operationsfurther comprising: determining a hierarchy of conditions based on a setof precedence values associated with the set of conditions; determininga pair of conflicting conditions based on the set of conditions and adifference in labels between category labels of the set of conditions,wherein each category label of a respective condition of the set ofconditions is one of a set of mutually exclusive category labels; anddetermining an overriding condition based on the hierarchy of governingconditions, wherein the overriding condition is one of the pair ofconflicting conditions, and wherein the overriding condition isindicated to take precedence over the other condition of the pair ofconflicting conditions.F-17. The medium of any of embodiments F-1 to F-16, the operationsfurther comprising: determining that a second cross-program entityidentifier is associated with the first entity; determining that acondition is associated with the second cross-program entity identifier;generating an association between the first cross-program entityidentifier and the second cross-program entity identifier in a databaseof cross-program entity identifiers; and persisting the database ofcross-program entity identifiers to a persistent storage of thecomputing system.F-18. The medium of embodiment F-17, the operations further comprisingsteps for obtaining the set of conditions.F-19. The medium of any of embodiments F-1 to F-18, the operationsfurther comprising steps for determining whether the set of conditionsis violated.F-20. A method to perform the operations of any of the embodiments F-1to F-19.F-21. A system, comprising: one or more processors; and memory storinginstructions that when executed by the processors cause the processorsto effectuate operations comprising: the operations of any one ofembodiments F-1 to F-19.J-1. A tangible, non-transitory, machine-readable medium storinginstructions that, when executed by a computer system, effectuateoperations comprising: obtaining, with a computer system, program stateof a self-executing protocol, wherein the program state comprises: a setof conditional statements; a first identifier of a first entity; and adirected graph, the directed graph comprising a set of vertices and aset of directed edges connecting respective pairs of vertices among theset of vertices, wherein each respective vertex of the set of verticesis associated with a respective category label of a set of mutuallyexclusive categories; receiving, at an application program interface ofthe computer system, an event message comprising a set of parameters;selecting, with the computer system, a first subset of verticestriggered by the event message based on the set of parameters;selecting, with the computer system, a second subset of vertices basedon the first subset of vertices, wherein the second subset of verticesis associated with the first subset of vertices via the set of directededges; determining, with the computer system, an aggregated parameterbased on a subset of conditional statements, wherein each respectiveconditional statement of the subset of conditional statements isassociated with a respective vertex of the second subset of vertices,and wherein the respective vertex is associated with a first categorylabel of the set of mutually exclusive categories that is associated toeach of the other vertices associated with the subset of conditionalstatements; and storing, with the computer system, the aggregatedparameter in memory.J-2. The medium of embodiment J-1, the operations further comprising:determining whether the event message is valid using a set of validatornodes of a peer-to-peer network, wherein each node of the peer-to-peernetwork is communicatively coupled to at least one other node of thepeer-to-peer network; in response to a determination that the eventmessage is valid, distributing a validation message indicating that theevent message is valid; and storing a value based on the event messageon a tamper-evident, distributed ledger encoding records of a pluralityof previous values in a directed acyclic graph of cryptographic hashpointers, wherein the tamper-evident, distributed ledger is stored onthe peer-to-peer network.J-3. The medium of embodiment J-2, wherein determining the first subsetof vertices comprises determining the first subset of vertices at afirst node of the peer-to-peer network before the validation message isreceived by the first node.J-4. The medium of any of embodiments J-1 to J-3, wherein the programstate further comprises a first identifier of a first entity, theoperations further comprising: determining whether the event message isvalid using a set of validator nodes of a peer-to-peer network; based ona determination that the event message is not valid, sending an issuenotification to a node of the peer-to-peer network associated with thefirst entity, wherein the issue notification comprises an identifier ofthe event message.J-5. The medium of any of embodiments J-1 to J-4, wherein the programstate further comprises a first identifier of a first entity, theoperations further comprising: determining a network path from a firstnode of a peer-to-peer network to a second node of the peer-to-peernetwork using a breadth first search, wherein: the first node receivedthe event message before the second node, the second node is associatedwith the first entity, and the network path comprises a plurality ofnodes of the peer-to-peer network; and sending data of the event messageto the second node from the first node via the network path.J-6. The medium of any of embodiments J-1 to J-5, wherein the eventmessage is a first event message, the operations further comprising:receiving a second event message within a duration threshold before orafter receiving the first event message; determining whether the secondevent message causes a vertex of the first subset of vertices totrigger; in response to a determination that the second event messagecauses the vertex of the first subset of vertices to trigger, obtaininga set of triggering parameters of the second event message, wherein theset of triggering parameters comprise values that satisfy a condition ofthe vertex; determining whether a first value of the first event messageand a second value of the second event message differ with respect tothe set of triggering parameters; and based on a determination that thefirst value matches the second value, updating a parameter associatedwith the second event message to indicate that the second event messageis a duplicate event message.J-7. The medium of any of embodiments J-1 to J-6, wherein the programstate further comprises a first identifier of a first entity and ansecond identifier of a second entity, the operations further comprising:retrieving a private conditional statement associated with the firstentity, wherein the private conditional statement is not stored inprogram state accessible to the second entity; and determining whetherthe private conditional statement is satisfied based on the first subsetof vertices or the second subset of vertices.J-8. The medium of any of embodiments J-1 to J-7, wherein a first storedvalue of the self-executing protocol is stored on a peer-to-peernetwork, and wherein a first node of the peer-to-peer network ispermitted to access the first stored value of the program state, andwherein a second node of the peer-to-peer network is not permitted toaccess the first stored value.J-9. The medium of any of embodiments J-1 to J-8, wherein determiningthe aggregated parameter comprises: determining that triggering a firstvertex of a pair of vertices of the directed graph causes thecancellation of a second vertex of the pair of vertices of the directedgraph, wherein the first vertex is associated with a first conditionalstatement and the second vertex is associated with a second conditionalstatement; selecting one of the pair parameters, the pair of parameterscomprising a first parameter of the first conditional statement and asecond parameter of the second conditional statement; and determiningthe aggregated parameter based on the first parameter.J-10. The medium of any of embodiments J-1 to J-9, wherein the programstate further comprises a first identifier of a first entity, andwherein the first entity is associated with an entity role, theoperations further comprising selecting the first entity, whereinselecting the first entity comprises: selecting a vertex of the firstsubset of vertices based on the set of parameters; and selecting thefirst entity based on the entity role being associated with the vertex.J-11. The medium of embodiment J-10, wherein a second entity isassociated the entity role, the operations further comprising sending asecond message to the second entity based on the second entity beingassociated with the entity role.J-12. The medium of any of embodiments J-1 to J-11, wherein the programstate further comprises a first identifier of a first entity, theoperations further comprising: determining that the first entity isassociated with an entity role; in response to a determination that thefirst entity is associated with the entity role, selecting a previousmessage from a history of messages based on the entity role; and sendingthe previous message to the first entity.J-13. The medium of any of embodiments J-1 to J-12, the operationsfurther comprising providing a user interface (UI), wherein verticesdisplayed in the UI are colored based on color associations withcategory labels associated with the vertices, and wherein eachrespective category label of the set of mutually exclusive categories isassociated with a different color.J-14. The medium of any of embodiments J-1 to J-13, wherein the programstate further comprises a first identifier of a first entity, theoperations further comprising: determining whether a first confirmationkey associated with a first representative of the first entity isreceived; determining whether a second confirmation key associated witha second representative the first entity is received; and in response toa determination that the first confirmation key and the secondconfirmation key is received, storing the first confirmation key and thesecond confirmation key in data storage in association with a record ofa transaction between a pair entities comprising the first entity.J-15. The medium of any of embodiments J-1 to J-14, wherein the programstate further comprises a first identifier of a first entity, theoperations further comprising; obtaining a score associated with thefirst entity, wherein the score is associated with a resource type; andupdating the score based on the set of parameters, wherein the set ofparameters comprises the resource type.J-16. The medium of any of embodiments J-1 to J-15, wherein determiningthe aggregated parameter comprises determining a sum of values, whereineach respective value used to determine the sum of values is encoded ina respective conditional statement of the subset of conditionalstatements.J-17. The medium of any of embodiments J-1 to J-16, the operationsfurther comprising providing a user interface (UI), wherein the UIvisually indicates the second subset of vertices based on a differencein color, difference in size, or difference in animation between thesecond subset of vertices and other vertices of the set of vertices.J-18. The medium of any of embodiments J-1 to J-17, wherein determiningthe first subset of vertices comprises steps for determining the firstsubset of vertices.J-19. The medium of any of embodiments J-1 to J-18, wherein determiningthe aggregated parameter comprises steps for determining the aggregatedparameter.J-20. A method to perform the operations of any of the embodiments J-1to J-19.J-21. A system comprising: one or more processors; and memory storinginstructions that, when executed by at least one of the one or moreprocessors, causes at least one of the one or more processors toeffectuate any of the operations of embodiments J-1 to J-19.

What is claimed is:
 1. A tangible, non-transitory, machine-readablemedium storing instructions that, when executed by a computer system,effectuate operations comprising: obtaining, with a computer system,program state of a self-executing protocol, wherein the program statecomprises: a set of conditional statements; a first identifier of afirst entity; and a directed graph, the directed graph comprising a setof vertices and a set of directed edges connecting respective pairs ofvertices among the set of vertices, wherein each respective vertex ofthe set of vertices is associated with a respective category label of aset of mutually exclusive categories; receiving, at an applicationprogram interface of the computer system, an event message comprising aset of parameters; selecting, with the computer system, a first subsetof vertices triggered by the event message based on the set ofparameters; selecting, with the computer system, a second subset ofvertices based on the first subset of vertices, wherein the secondsubset of vertices is associated with the first subset of vertices viathe set of directed edges; determining, with the computer system, anaggregated parameter based on a subset of conditional statements,wherein each respective conditional statement of the subset ofconditional statements is associated with a respective vertex of thesecond subset of vertices, and wherein the respective vertex isassociated with a first category label of the set of mutually exclusivecategories that is associated to each of the other vertices associatedwith the subset of conditional statements; and storing, with thecomputer system, the aggregated parameter in memory.
 2. The medium ofclaim 1, the operations further comprising: determining whether theevent message is valid using a set of validator nodes of a peer-to-peernetwork, wherein each node of the peer-to-peer network iscommunicatively coupled to at least one other node of the peer-to-peernetwork; in response to a determination that the event message is valid,distributing a validation message indicating that the event message isvalid; and storing a value based on the event message on atamper-evident, distributed ledger encoding records of a plurality ofprevious values in a directed acyclic graph of cryptographic hashpointers, wherein the tamper-evident, distributed ledger is stored onthe peer-to-peer network.
 3. The medium of claim 2, wherein determiningthe first subset of vertices comprises determining the first subset ofvertices at a first node of the peer-to-peer network before thevalidation message is received by the first node.
 4. The medium of claim1, wherein the program state further comprises a first identifier of afirst entity, the operations further comprising: determining whether theevent message is valid using a set of validator nodes of a peer-to-peernetwork; based on a determination that the event message is not valid,sending an issue notification to a node of the peer-to-peer networkassociated with the first entity, wherein the issue notificationcomprises an identifier of the event message.
 5. The medium of claim 1,wherein the program state further comprises a first identifier of afirst entity, further comprising: determining a network path from afirst node of a peer-to-peer network to a second node of thepeer-to-peer network using a breadth first search, wherein: the firstnode received the event message before the second node, the second nodeis associated with the first entity, and the network path comprises aplurality of nodes of the peer-to-peer network; and sending data of theevent message to the second node from the first node via the networkpath.
 6. The medium of claim 1, wherein the event message is a firstevent message, the operations further comprising: receiving a secondevent message within a duration threshold before or after receiving thefirst event message; determining whether the second event message causesa vertex of the first subset of vertices to trigger; in response to adetermination that the second event message causes the vertex of thefirst subset of vertices to trigger, obtaining a set of triggeringparameters of the second event message, wherein the set of triggeringparameters comprise values that satisfy a condition of the vertex;determining whether a first value of the first event message and asecond value of the second event message differ with respect to the setof triggering parameters; and based on a determination that the firstvalue matches the second value, updating a parameter associated with thesecond event message to indicate that the second event message is aduplicate event message.
 7. The medium of claim 1, wherein the programstate further comprises a first identifier of a first entity and ansecond identifier of a second entity, the operations further comprising:retrieving a private conditional statement associated with the firstentity, wherein the private conditional statement is not stored inprogram state accessible to the second entity; and determining whetherthe private conditional statement is satisfied based on the first subsetof vertices or the second subset of vertices.
 8. The medium of claim 1,wherein a first stored value of the self-executing protocol is stored ona peer-to-peer network, and wherein a first node of the peer-to-peernetwork is permitted to access the first stored value of the programstate, and wherein a second node of the peer-to-peer network is notpermitted to access the first stored value.
 9. The medium of claim 1,wherein determining the aggregated parameter comprises: determining thattriggering a first vertex of a pair of vertices of the directed graphcauses the cancellation of a second vertex of the pair of vertices ofthe directed graph, wherein the first vertex is associated with a firstconditional statement and the second vertex is associated with a secondconditional statement; selecting one of the pair parameters, the pair ofparameters comprising a first parameter of the first conditionalstatement and a second parameter of the second conditional statement;and determining the aggregated parameter based on the first parameter.10. The medium of claim 1, wherein the program state further comprises afirst identifier of a first entity, and wherein the first entity isassociated with an entity role, the operations further comprisingselecting the first entity, wherein selecting the first entitycomprises: selecting a vertex of the first subset of vertices based onthe set of parameters; and selecting the first entity based on theentity role being associated with the vertex.
 11. The medium of claim10, wherein a second entity is associated the entity role, theoperations further comprising sending a second message to the secondentity based on the second entity being associated with the entity role.12. The medium of claim 1, wherein the program state further comprises afirst identifier of a first entity, the operations further comprising:determining that the first entity is associated with an entity role; inresponse to a determination that the first entity is associated with theentity role, selecting a previous message from a history of messagesbased on the entity role; and sending the previous message to the firstentity.
 13. The medium of claim 1, the operations further comprisingproviding a user interface (UI), wherein vertices displayed in the UIare colored based on color associations with category labels associatedwith the vertices, and wherein each respective category label of the setof mutually exclusive categories is associated with a different color.14. The medium of claim 1, wherein the program state further comprises afirst identifier of a first entity, the operations further comprising:determining whether a first confirmation key associated with a firstrepresentative of the first entity is received; determining whether asecond confirmation key associated with a second representative thefirst entity is received; and in response to a determination that thefirst confirmation key and the second confirmation key is received,storing the first confirmation key and the second confirmation key indata storage in association with a record of a transaction between apair entities comprising the first entity.
 15. The medium of claim 1,wherein the program state further comprises a first identifier of afirst entity, the operations further comprising; obtaining a scoreassociated with the first entity, wherein the score is associated with aresource type; and updating the score based on the set of parameters,wherein the set of parameters comprises the resource type.
 16. Themedium of claim 1, wherein determining the aggregated parametercomprises determining a sum of values, wherein each respective valueused to determine the sum of values is encoded in a respectiveconditional statement of the subset of conditional statements.
 17. Themedium of claim 1, the operations further comprising providing a userinterface (UI), wherein the UI visually indicates the second subset ofvertices based on a difference in color, difference in size, ordifference in animation between the second subset of vertices and othervertices of the set of vertices.
 18. The medium of claim 1, whereindetermining the first subset of vertices comprises steps for determiningthe first subset of vertices.
 19. The medium of claim 1, whereindetermining the aggregated parameter comprises steps for determining theaggregated parameter.
 20. A method comprising: obtaining, with acomputer system, program state of a self-executing protocol, wherein theprogram state comprises: a set of conditional statements; a firstidentifier of a first entity; and a directed graph, the directed graphcomprising a set of vertices and a set of directed edges connectingrespective pairs of vertices among the set of vertices, wherein eachrespective vertex of the set of vertices is associated with a respectivecategory label of a set of mutually exclusive categories; receiving, atan application program interface of the computer system, an eventmessage comprising a set of parameters; selecting, with the computersystem, a first subset of vertices triggered by the event message basedon the set of parameters; selecting, with the computer system, a secondsubset of vertices based on the first subset of vertices, wherein thesecond subset of vertices is associated with the first subset ofvertices via the set of directed edges; determining, with the computersystem, an aggregated parameter based on a subset of conditionalstatements, wherein each respective conditional statement of the subsetof conditional statements is associated with a respective vertex of thesecond subset of vertices, and wherein the respective vertex isassociated with a first category label of the set of mutually exclusivecategories that is associated to each of the other vertices associatedwith the subset of conditional statements; and storing, with thecomputer system, the aggregated parameter in memory.